How should the route-level global timeout be used in comparison with the QoS timeout in versions 23.3.0 - 24.0.1 ?

[Liliya-Nuraly]

Hello, we have been struggling with this issue for several weeks now. We need to disable retry, but keep timeout. We use QoSOptions for this and enable AddPolly(). On some endpoints, we need to have a timeout, but not repeat requests if the request fails due to a timeout or any other error. The problem is that we run a query, it works out the time allocated to it from the timeout QoSOptions and falls off, and then immediately runs two of the same queries in a row and falls off on them by timeout. We tried different ways: delegates, change configuration, disable polly. When we disable polly, the requests are not repeated, but the problem remains the same. We need a timeout, but without Polly, everything falls off after a minute and a half. The delegates don't help, it's like he doesn't see them. A timeout that does not belong to QoSOptions does not work. Please tell me what can be done in this case! Ocelot 24v

[raman-m]

Hello!
Please share your ocelot.json file, as it's hard to provide proper guidance without seeing an actual configuration.

We need to disable retry, but keep timeout. We use QoSOptions for this and enable AddPolly().

For the current versions 24.0.* the answer → Timeout strategy

"QoSOptions": {
  "TimeoutValue": 5000 // ms
}

Don't specify other options at all!

FYI

A default timeout feature without QoS has been implemented in this commit: 7c583bf. However, it is still located in development branch, and it will be released in version 24.1.0

[Liliya-Nuraly]

We are sending you ocelot.json, logs, and program.cs.
program.txt
ocelot_log.txt
ocelot.json

[raman-m]

From your ocelot.json:

            "QoSOptions": {
                "TimeoutValue": 600000 // 600 seconds -> 10 minutes
            },

This means attempting a 600-second timeout won't work because of the current issue with QoS versus Route timeout priorities, where the Route default 90-second timeout triggers the event before the QoS 600-second timeout. To be fair, this isn't a bug but rather a design limitation in version 24.0, where the Route timeout is shorter than the QoS timeout. Did you read these Notes?
FYI Timeout is not configurable per route without QoS, but the global timeout for routes can be configured via C# (refer to my answer below). Just to note, this issue occurs only in version 24.0.* and earlier versions.

[Liliya-Nuraly]

The timeout worked fine. Please note that it has run a second query. I want to understand why this is happening.

[raman-m]

I want to understand why this is happening.

I assume it might be your custom delegating handler that needs to be reviewed. You should provide the complete solution, including the delegating handler, and ensure it is uploaded to your GitHub account for our review.

The second strategy involves removing the custom delegating handler and testing the bug again. Please share your testing results with us.

[raman-m]

We need a timeout, but without Polly, everything falls off after a minute and a half.

That's correct, as the default 90-second timeout triggers the event as mentioned in our QoS Notes. To adjust the route global timeout duration, whether longer or shorter, you can use the C# recipe provided below. Currently, in versions 24.0.*, this is an undocumented feature (refer to MessageInvokerPool.cs#L35-L38 lines).

The delegates don't help, it's like he doesn't see them.

Using delegate handlers to solve the problem can be quite risky since the current timeout feature design relies on the TimeoutDelegatingHandler class. Please stop doing this!

A timeout that does not belong to QoSOptions does not work. Please tell me what can be done in this case! Ocelot 24v

Route timeout is not implemented at all in v24.0! There is global route timeout only, but it is undocumented! 😃
Check our v24.0 documentation for any mention of timeout feature, you won’t find anything about route timeouts, except perhaps in the Notes section of the QoS chapter, where we explain the current global 90-second route timeout.
The documentation mentions, "To request additional configurability, consider opening an issue." Issues #1314, #1869, and #2072 have already been raised. The route timeout feature was implemented in PR #2073, merged into the develop branch as a commit 7c583bf, but it has not yet been released, and it will be released in version 24.1.0.
You could read our Development docs →

• Timeout configuration, it is developed but not released!
• QoS Timeout strategy, it is developed but not released!
• QoS Notes with many mentions of timeouts

Until the release of the new v24.1 package, please use the following C# recipe to configure global route timeout aka Default timeout, in your Program.cs write this code:

using Ocelot.DependencyInjection;
using Ocelot.Middleware;
using Ocelot.Requester;

// ...
var app = builder.Build();

// Because the IMessageInvokerPool service is a singleton, ...
var service = app.Services.GetService(typeof(IMessageInvokerPool)) as MessageInvokerPool;
// ...we will assign a global default timeout for all routes (600 seconds)
service.RequestTimeoutSeconds = 600; // (QoSOptions.TimeoutValue / 1000) seconds

await app.UseOcelot();
await app.RunAsync();

Notes

1. Please keep in mind that all QoSOptions.TimeoutValue timespans must be less than 600 seconds; otherwise, QoS timeouts will not function properly.
2. Please note that the recipe above is valid for versions 23.3.0 through 24.0.0, including the current version 24.0.1. In the upcoming version 24.1.0 (targeted for the Summer '25 milestone), the new Timeout feature will be introduced.

Hope this helps!

[Liliya-Nuraly]

Thanks for the answer! We will be looking forward to 24.1.0.

[raman-m]

Just a heads-up, the release of version 24.1 is scheduled for about a month from now, either in the last days of August or the start of September.