Circuit Breaker or Timeout Configuration Not Working as Expected in Ocelot

[aftabkajal]

I am using Ocelot as my API Gateway and have configured QoS options to include a circuit breaker and timeout for downstream requests. However, the behavior is not working as expected. Specifically:

Timeout Behavior:

When the TimeoutValue is set (e.g., 3000ms), requests taking longer than the specified duration do not always return a timeout error. Instead, the requests continue and eventually return the downstream response.

Circuit Breaker Behavior:

While testing the ExceptionsAllowedBeforeBreaking functionality, I noticed that the circuit breaker does not transition to the "Open" state after the specified number of exceptions.

Despite setting ExceptionsAllowedBeforeBreaking to a value (e.g., 3), the circuit breaker does not seem to open even when more exceptions than the allowed threshold are encountered consecutively.

Reproduction Steps:

• Set up Ocelot with the above configuration.
• Simulate a downstream service delay greater than TimeoutValue (e.g., 4000ms).
• Trigger exceptions by returning HTTP 500 responses from the downstream service for at least 3 consecutive requests. Observe Ocelot's behavior with regards to timeouts and the circuit breaker state.

Configuration used in global configuration and route level:
"QoSOptions": {
"TimeoutValue": 3000,
"DurationOfBreak": 2000,
"ExceptionsAllowedBeforeBreaking": 3
}

Specifications

• Version: 23.4.2
• Platform: Docker
• Subsystem: Linux

[aftabkajal]

This issue has been resolved my-self.

[raman-m]

Hello, Md. Aftab!
🆗 What was wrong?

Timeout Behavior:
When the TimeoutValue is set (e.g., 3000ms), requests taking longer than the specified duration do not always return a timeout error. Instead, the requests continue and eventually return the downstream response.

What is the frequency with which you have encountered this? What proportion of the total number of requests does it represent?

P.S.

Please aware that the Timeout logic may be quite unstable, and sometimes a timeout event can be triggered of the specified period. We are going to refactor the Timeout logic by migrating to the .NET SocketsHttpHandler class →

• TODOs Reuse theocketsHttpHandler class
• The development plan is described in Query regarding `QoSOptions` implemention in version 23.2+ #2112 (comment)

[aftabkajal]

Hello @raman-m ,

I am currently facing an issue (#2241) and would greatly appreciate your assistance in resolving it. This is quite urgent for me, and your guidance would be incredibly helpful.

Looking forward to your response.