Ocelot: Exception caught in global error handler, exception message: Object reference not set to an instance of an object.

Expected Behavior

I’m expecting to get error details coming from ocelot.json file validation in case of invalid configuration being provided.

Actual Behavior

I had scenario where Errors collection coming from validation process (ocelot.json) is discarded and then I’m getting NullReferenceException instead which is hiding the real problem.

Exception caught in global error handler, exception message: Object reference not set to an instance of an object., exception stack:    
at Ocelot.Errors.Middleware.ExceptionHandlerMiddleware.TrySetGlobalRequestId(HttpContext httpContext, IInternalConfiguration configuration)\n   
at Ocelot.Errors.Middleware.ExceptionHandlerMiddleware.Invoke(HttpContext httpContext)

Steps to Reproduce the Problem

You have to create ocelot.json file where one of the routes contains something like this:

"DownstreamPathTemplate": "{everything}"

During debugging Ocelot I got at some point Errors collection with message: “Downstream Path Template {everything} doesnt start with forward slash” It was in method Ocelot.Middleware.OcelotMiddlewareExtensions.CreateConfiguration’IApplicationBuilder -> fileConfig.OnChange callback

Ocelot.dll!Ocelot.Configuration.Repository.InMemoryInternalConfigurationRepository.AddOrReplace(Ocelot.Configuration.IInternalConfiguration internalConfiguration) Line 27	C#
>	Ocelot.dll!Ocelot.Middleware.OcelotMiddlewareExtensions.CreateConfiguration.AnonymousMethod__0(Ocelot.Configuration.File.FileConfiguration config) Line 98	C#
 	Microsoft.Extensions.Options.dll!Microsoft.Extensions.Options.OptionsMonitorExtensions.OnChange.AnonymousMethod__0(System.__Canon o, string _)	Unknown

nevertheless somehow this mesage was never logged anywhere, it was discarded and finally I got NullReferenceException instead

{Ocelot.Responses.ErrorResponse<Ocelot.Configuration.IInternalConfiguration>} -> Data -> null in my case -> Errors -> Downstream Path Template {everything} doesnt start with forward slash -> IsError -> true

In line

internalConfigRepo.AddOrReplace(newInternalConfig.Data);

error should be checked before accessing .Data property

Specifications

Version: 17.0.0, 17.0.1
Platform: Windows/Linux
Subsystem: -

About this issue

Original URL
State: open
Created 2 years ago
Reactions: 1
Comments: 16 (14 by maintainers)

Most upvoted comments

@klaudiusz-czapla Hi, I am unable to replicate NullReferenceException, when configuration is bad. I can see following validation code which doesn’t allow to start application even.

My Route in Ocelot.json file is, here I removed first slash of downstream path.

 "Routes": [
   {
     "DownstreamHostAndPorts": [
       {
         "Host": "localhost",
         "Port": 5022
       },
       {
         "Host": "localhost",
         "Port": 5085
       }
     ],
     "ServiceName": "ConsulDemo",
     "LoadBalancerOptions": {
       "Type": "LeastConnection"
     },
     "UpstreamPathTemplate": "/hostname",
     "UpstreamHttpMethod": [ "GET" ],
     "DownstreamPathTemplate": "WeatherForecast/hostname",
     "DownstreamScheme": "http",
     "DangerousAcceptAnyServerCertificateValidator": true


   }
 ]

@raman-m Not sure what he was trying to explain last year, but on latest version I am unable to see any issue. @klaudiusz-czapla Feel free to add any point here if I missed anything, else @raman-m we can close this. Thanks!

ks1990cn on Dec 1, 2023

Maybe, you configured duplication the endpoint about downstream/upstream url

ntruongvux on Jul 3, 2023

Okay, but code stops running before that at line 85.

ks1990cn on Dec 4, 2023

@ks1990cn It seems the problem is inside the async anonymous callback: fileConfig.OnChange…

The quote from the description:

In line
internalConfigRepo.AddOrReplace(newInternalConfig.Data);
error should be checked before accessing .Data property

raman-m on Dec 4, 2023

@raman-m Error message which I’ve posted was extracted by myself during debugging. In the runtime it was hidden from the user. Btw NullReferenceException should never be thrown by the application. It should be handled somehow. As I said - original error message was hidden. Without debugging Ocelot code I would never be able to get to know what was wrong and misconfigured 😃

klaudiusz-czapla on Jul 3, 2023