Thanks for the question @ Lisa.

@Lauren,

Thank you for the suggestions on avoiding the timeout toggle by configuring retries or increasing the timeout value. I believe these are viable solutions, but I wanted to share some concerns and suggestions regarding the configuration of retries with a view to finding the right balance between reliability and network performance.

Currently, with the polling frequency set at every 10 seconds and the timeout set to 5 seconds, I understand the retries would help mitigate the effects of transient errors. However, if we introduce retries, there’s a potential for increasing network overhead, especially if errors occur frequently.

To avoid this, please do vet some adjustments that I am thinking through and advise accordingly:

Limit the number of retries: Perhaps starting with a conservative retry value (e.g., 1 or 2 retries) to avoid overwhelming the network with unnecessary requests.

Exponential backoff: If the system allows, implementing an exponential backoff for retries would prevent rapid successive retries, which could add unnecessary load on the endpoint.

Monitoring performance: Before making aggressive changes, it may also be worth monitoring the endpoint’s performance over a period of time to ensure that these issues aren’t stemming from underlying network or server-side problems.