TimeoutException, a task was canceled
Error Description
When attempting to execute an API call, the task may encounter a timeout. Depending on the configuration of the ExceptionHandlingStrategy
, different outcomes will occur.
If
ExceptionHandlingStrategy
is set toThrow
, an exception will be thrown when a timeout occurs.If
ExceptionHandlingStrategy
is configured otherwise, such asReturnNull
, the user will receive a null value instead of an exception. Regardless of the outcome, internal exceptions are logged.
Applies to
UOF SDK for .NET (both versions)
Symptoms
All API calls have specified timeouts configured. Calls related to summary, single variant markets, draw summary, competitor profiles, and player profiles are considered time-critical and are configured with a HttpClientFastFailingTimeout
(defaulting to 5 seconds), while other calls use HttpClientTimeout
(defaulting to 30 seconds).
In the execution log user can search for TaskCanceledException (.NET) and TimeoutException (java).
Resolution
To address this issue, users can take the following steps:
Configure HTTP Client Timeout Settings: Users should configure the HTTP client timeout settings before initializing the SDK. Adjust
HttpClientFastFailingTimeout
andHttpClientTimeout
based on the specific requirements and criticality of the API calls. Both timeouts can be configured via ConfigurationBuilder. Warning: if user increases timeout it will be applied to all requests that uses that timeout and so affecting messaging processing time. I.e. if the customer is processing messages in the critical path, increasing timeout for summary will increase timeout for a lot of other calls, some of which might appear on the critical path increasing a likelihood of producer being marked as down and causing delays of messages.Retry API Calls: In case of timeouts, users can implement retry logic to attempt the API call again later. You should consider scheduling the API call for later execution in a separate thread to prevent delays in message processing. It's recommended to handle retries manually to avoid delays in message processing, as the SDK does not provide automatic retry functionality to minimize processing time on critical paths.
Check if same request is working via iodocs swagger interface
Depending on the logging configuration of the SDK on the customer end, SDK might produces log to different files. One of the files is rest-log containing only log lines related to API invocations. We recommend consulting this log to find more information about the failure as it usually contains HTTP response codes and response bodies. Currently log lines in different files can be linked only via timestamp and thread name if the customer logging configuration includes it.
Last updated
Was this helpful?