Thursday 15 June 2023

git pull error :error: remote ref is at but expected

Today I faced strange GIT error while running GIT pull command.

error: cannot lock ref 'refs/remotes/origin/Feature/Performance_Fix': is at 121133f24b3eda9c7167c7be2b0f31d282b0bbb2 but expected 58840e344e3d301761c726e4f833b83f6b261ecb

Solution : 

Run below commands to fix this issue (Update the object name stored in a ref safely, used this to delete the reference) 

git update-ref -d refs/remotes/origin/Feature/Performance_Fix

git pull


Thursday 8 June 2023

Error : The specified type member 'Date' is not supported in LINQ to Entities

I was trying to use Date property of DateTime field in LINQ query but got this error.

Message = "The specified type member 'Date' is not supported in LINQ to Entities. Only initializers, entity members, and entity navigation properties are supported."

Example query : 

var query = from employeeRecord in _context.EmployeeRecord 

                   where (employeeRecord.StartDate.Date== currentDate)

Solution : Use DbFunctions.TruncateTime to truncate time part from a DateTime.

Updated Query : 

var query = from employeeRecord in _context.EmployeeRecord 

                   where (DbFunctions.TruncateTime(employeeRecord.StartDate) == currentDate)

Saturday 1 April 2023

Error while upgrading Azure function to .NET6

I was  upgrading a Function App from using version 4.0.0 of Microsoft.Azure.WebJobs.Extensions.Storage to 5.1.0 and then the app crashed on startup with the following error: 

 Error : A host error has occurred during startup operation 'dea811a2-8241-4581-a014-2f94a0aad978'. [2023-03-31T22:00:31.493Z] Microsoft.Azure.WebJobs.Extensions.ServiceBus: Could not load type 'Microsoft.Azure.WebJobs.ParameterBindingData' from assembly 'Microsoft.Azure.WebJobs, Version=3.0.34.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. 

Solution : 
  1. Downgrade to, "Microsoft.Azure.WebJobs.Extensions.Storage" version: 5.0.1 
  2. Clean the solution and run it

Thursday 19 January 2023

InvalidOperationException: Can't use schemaId for type The same schemaId is already used for type

 After adding new bean to project I got below error during startup


13:44:19:254 ---> System.InvalidOperationException: Can't use schemaId "$Employee" for type "$staff.Employee". The same schemaId is already used for type "$test.Employee" 13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SchemaRepository.RegisterType(Type type, String schemaId) 13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SchemaGenerator.GenerateReferencedSchema(DataContract dataContract, SchemaRepository schemaRepository, Func`1 definitionFactory) 13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SchemaGenerator.GenerateConcreteSchema(DataContract dataContract, SchemaRepository schemaRepository) 13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SchemaGenerator.GenerateSchemaForType(Type modelType, SchemaRepository schemaRepository) 13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SchemaGenerator.GenerateSchema(Type modelType, SchemaRepository schemaRepository, MemberInfo memberInfo, ParameterInfo parameterInfo) 13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SchemaGenerator.CreateArraySchema(DataContract dataContract, SchemaRepository schemaRepository) 13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SchemaGenerator.<>c__DisplayClass10_0.b__1() 13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SchemaGenerator.GenerateConcreteSchema(DataContract dataContract, SchemaRepository schemaRepository) 13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SchemaGenerator.GenerateSchemaForParameter(Type modelType, SchemaRepository schemaRepository, ParameterInfo parameterInfo) 13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SchemaGenerator.GenerateSchema(Type modelType, SchemaRepository schemaRepository, MemberInfo memberInfo, ParameterInfo parameterInfo) 13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SwaggerGenerator.GenerateSchema(Type type, SchemaRepository schemaRepository, PropertyInfo propertyInfo, ParameterInfo parameterInfo) 13:44:19:254 --- End of inner exception stack trace --- 13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SwaggerGenerator.GenerateSchema(Type type, SchemaRepository schemaRepository, PropertyInfo propertyInfo, ParameterInfo parameterInfo) 13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SwaggerGenerator.GenerateRequestBodyFromBodyParameter(ApiDescription apiDescription, SchemaRepository schemaRepository, ApiParameterDescription bodyParameter) 13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SwaggerGenerator.GenerateRequestBody(ApiDescription apiDescription, SchemaRepository schemaRepository) 13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SwaggerGenerator.GenerateOperation(ApiDescription apiDescription, SchemaRepository schemaRepository) 13:44:19:254 --- End of inner exception stack trace --- 13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SwaggerGenerator.GenerateOperation(ApiDescription apiDescription, SchemaRepository schemaRepository) 13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SwaggerGenerator.GenerateOperations(IEnumerable`1 apiDescriptions, SchemaRepository schemaRepository) 13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SwaggerGenerator.GeneratePaths(IEnumerable`1 apiDescriptions, SchemaRepository schemaRepository) 13:44:19:254 at Swashbuckle.AspNetCore.SwaggerGen.SwaggerGenerator.GetSwagger(String documentName, String host, String basePath) 13:44:19:254 at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider) 13:44:19:254 at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context) 13:44:19:254 at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

Solution : 

The only change needed is in your Startup.cs inside the method ConfigureServices.

You should add the following:

services.AddSwaggerGen(options =>

{

    options.CustomSchemaIds(type => type.ToString());

});

Wednesday 7 December 2022

How do I fix dependency conflicts in npm install?

Today I was working on a front end app. I faced below error while running npm install command.


npm ERR! Conflicting peer dependency: @angular/core@6.1.10

npm ERR! node_modules/@angular/core

npm ERR!   peer @angular/core@"^6.0.3" from @angular-redux/router@9.0.0

npm ERR!   node_modules/@angular-redux/router

npm ERR!     @angular-redux/router@"^9.0.0" from the root project


Fix for Conflicting peer dependency in node.js

  • Downgrade the npm version to the previous version.
  • remove the node_modules folder.
  • remove package-lock.json.
  • please do npm install one more time to do a fresh installation of the dependency.

Saturday 12 March 2022

Detecting a active transaction in spring application

Sometimes we need to use transactions (@Transactional) in code. We use @Transactional annotation on class and method to generate transactions.

In order to troubleshoot transaction issues, it could be helpful to verify if we have an active transaction in the current method or not.

Spring has provided a class called TransactionSychronizationManager. This class has a static method that allows us to know whether we are in a transaction (active transaction or no transaction), called isActualTransactionActive().

You can call this method and print output in logs. It will be true for active transactions false otherwise.

For example :

logger.error("Transaction is active " + TransactionSynchronizationManager.isActualTransactionActive());

Sunday 19 December 2021

Microservices Best Practices for the Optimal Architecture Design

Microservices have fundamentally changed the way server side applications are architected. Rather than a single giant monolithic codebase hosting all the business logic of your application, microservices reflect the distributed systems model, where a group of application components work together to deliver the business needs.

1. The Single Responsibility Principle

Just like with code, where a class should have only a single reason to change, microservices should be modeled in a similar fashion. Building bloated services which are subject to change for more than one business context is a bad practice.

2. Have a separate data store(s) for your microservice

It defeats the purpose of having microservices if you are using a monolithic database that all your microservices share. Any change or downtime to that database would then impact all the microservices that use the database. Choose the right database for your microservice needs, customize the infrastructure and storage to the data that it maintains, and let it be exclusive to your microservice. Ideally, any other microservice that needs access to that data would only access it through the APIs that the microservice with write access has exposed. 


3. Use asynchronous communication to achieve loose coupling

To avoid building a mesh of tightly coupled components, consider using asynchronous communication between microservices. 

4. Fail fast by using a circuit breaker to achieve fault tolerance

If your microservice is dependent on another system to provide a response, and that system takes forever to respond, your overall response SLAs will be impacted. To avoid this scenario and quickly respond, one simple microservices best practice you can follow is to use a circuit breaker to timeout the external call and return a default response or an error. This will isolate the failing services that your service is dependent on without causing cascade failures, keeping your microservice in good health. You can choose to use popular products like Hystrix that Netflix developed.

5. Proxy your microservice requests through an API Gateway

Instead of every microservice in the system performing the functions of API authentication, request / response logging, and throttling, having an API gateway doing these for you upfront will add a lot of value. Clients calling your microservices will connect to the API Gateway instead of directly calling your service. This way you will avoid making all those additional calls from your microservice and the internal URLs of your service would be hidden, giving you the flexibility to redirect the traffic from the API Gateway to a newer version of your service. This is even more necessary when a third party is accessing your service, as you can throttle the incoming traffic and reject unauthorized requests from the API gateway before they reach your microservice. You can also choose to have a separate API gateway that accepts traffic from external networks. 

6. Ensure your API changes are backwards compatible

You can safely introduce changes to your API and release them fast as long as they don’t break existing callers. 

7. Version your microservices for breaking changes

It's not always possible to make backwards compatible changes. When you are making a breaking change, expose a new version of your endpoint while continuing to support older versions. Consumers can choose to use the new version at their convenience. However, having too many versions of your API can create a nightmare for those maintaining the code. Hence, have a disciplined approach to deprecate older versions by working with your clients or internally rerouting the traffic to the newer versions.

8. Have dedicated infrastructure hosting your microservice

You can have the best designed microservice meeting all the checks, but with a bad design of the hosting platform it would still behave poorly. Isolate your microservice infrastructure from other components to get fault isolation and best performance. It is also important to isolate the infrastructure of the components that your microservice depends on.

9. Create a separate release train

Your microservice needs to have its own separate release vehicle which is not tied to other components within your organization. This way you are not stepping on each other’s toes and wasting time coordinating with multiple teams.

10. Create Organizational Efficiencies

While microservices give you the freedom to develop and release independently, certain standards need to be followed for cross cutting concerns so that every team doesn’t spend time creating unique solutions for these. This is very important in a distributed architecture such as microservices, where you need to be able to connect all the pieces of the puzzle to see a holistic picture. Hence, enterprise solutions are necessary for API security, log aggregation, monitoring, API documentation, secrets management, config management, distributed tracing, etc. 

By following these microservices best practices, you should end up with a loosely coupled, distributed, and independent microservice system, wherein you can achieve the true benefits of a microservices architecture as listed at the beginning of this article.