How to configure Polly v8 with the Ocelot 23.2.2?

[anonimousspider]

In Polly v8, we have observed that the circuit breaker functionality is not working as expected. We have experienced issues where the circuit breaker does not trip or reset correctly, leading to inconsistent fault handling. Conversely, in Polly v7, the circuit breaker also exhibits problems, failing to operate smoothly in certain scenarios.
Circuit Breaker Not Tripping

Example

Suppose you have configured an Ocelot route with a circuit breaker policy to trip after three consecutive HTTP request failures:
Route Configuration:

{
  "Routes": [
    {
      "DownstreamPathTemplate": "/api/StudentIdentity/Verify ",
      "DownstreamScheme": "https",
      "DownstreamHostAndPorts": [
        {
          "Host": "localhost", "Port": 5001
        }
      ],
      "UpstreamPathTemplate": " api/student/Verify ",
      "UpstreamHttpMethod": [ "Get" ],
      "QoSOptions": {
        "ExceptionsAllowedBeforeBreaking": 3,
        "DurationOfBreak": 10000,
        "TimeoutValue": 5000
      }
    }
  ]
}

Configuration in Program.cs for V7:

services.AddLogging(logging =>
 {
     logging.ClearProviders();
     logging.AddConsole();
                            
 });
 services.AddJwtAuthentication();
 services.AddOcelot().AddPollyV7();

Configuration in program.cs using Polly V8:

services.AddLogging(logging =>
 {
     logging.ClearProviders();
     logging.AddConsole();
                            
 });
 services.AddJwtAuthentication();
 services.AddOcelot().AddPolly();

Expected Behaviour

During runtime, the downstream service fails five consecutive times. The circuit breaker should trip and stop the request to be forwarded , and move to open state as per configured.

Actual behavior

During runtime, the downstream service fails five consecutive times. Despite this, the circuit breaker does not trip and continues to forward requests, instead of moving to the open state after three failures as configured.

Scenario 1

When service response is delayed from the service configured in ocelot.
PollyV7: Its working fine
PollyV8: on applying pollyv8 in the gateway not Working.

Scenario 2

When service is giving 503 error response .
Polly v7 : Its working Fine
Polly v8: Not working.

Scenario 3

When Service is giving 404 error response.
Polly v7 : working fine.
Polly v8: Not working.

---

Can you please suggest, how to configure Polly v8 with the current Ocelot version 23.2.2?

[raman-m]

@anonimousspider, thank you for your question! Could you please provide your full name?
Welcome to the world of Ocelot! 🐯

It seems you're experiencing issues with the V7 provider. However, since the QoS package has been updated to the latest Polly version (V8 syntax), we advise using only Ocelot's AddPolly which is V8.
For your information, we plan to completely phase out the V7 provider in Ocelot v23.3 (the current release).
For more details, refer to PR #2079.

[raman-m]

@RaynaldM, your client is here! 😉 Could you provide further advice to the developer, please?
Are there similar acceptance tests that are more closely related to the problem?

[raman-m]

Official Polly documentation

• Meet Polly: The .NET resilience library
• Resilience pipelines

Official Ocelot documentation

• Quality of Service

What's your full name?
What's your LinkedIn?

[RaynaldM]

Hi Anonimous, I'm trying to reproduce your case.
First, according to this list , 404 is not a circuit-breaker launcher, you could use you own ServerErrorCodes to add it

[RaynaldM]

The unit test that checks that the circuit-breaker is working correctly is here, I've run it, and it validates that the process is running correctly :

I don't know what more I can do for you in fact, no :
I have found a probable issue with strategies order, PR is running #2086 (issue #2085)

[raman-m]

OK, PR #2086 will officially close this discussion...

[raman-m]

You must upload the solution as a new repo to your GiHub account❗

[raman-m]

WeatherForecast 🤣
WeatherForecastController

Why do you have unnecessary controllers in gateway project? That's absolutely wrong from the view point of Microservices architecture!
All data controllers must be moved to downstream service project!

Also, the ocelot.json file is overly extensive and contains superfluous JSON properties. It should be condensed to a shorter version to avoid errors in route configuration. Only the necessary JSON sections and options need to be defined.

I'm asking once again...

• What's your full name?
• What's your LinkedIn ?

I will postpone any feedback until you answer these questions. I'm not fond of conversing with anonymous individuals.

[RaynaldM]

For me, your sample seems to be correct. I don't unsderstand where is the issue

[raman-m]

@RaynaldM
This user is blocked! The thread will be closed. This is my decision...
Please disregard all anonymous inquiries. Thank you!