You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The original v1 version of Requester included an additive backoff/retry loop for execute_request(). This logic does not appear to have been ported to the v2 Requester class. Unfortunately, HTTPError(429) and URLError(Timeout) both can raise exceptions that will interrupt an iteration in progress. Because we want to allow uninterrupted iteration over things like Incident.list(), any applicable retries should occur before raising these exceptions.
This retry logic is especially pertinent for multi-threading, as (for example) a parent thread may iterate over incidents, while child threads iterate over log_entries. There should be an expectation that rapid requests from the child, causing HTTP 429, should not raise an exception in the parent thread iterator as it does today.
The text was updated successfully, but these errors were encountered:
For tracking purposes.
The original v1 version of
Requester
included an additive backoff/retry loop forexecute_request()
. This logic does not appear to have been ported to the v2Requester
class. Unfortunately,HTTPError(429)
andURLError(Timeout)
both can raise exceptions that will interrupt an iteration in progress. Because we want to allow uninterrupted iteration over things likeIncident.list()
, any applicable retries should occur before raising these exceptions.This retry logic is especially pertinent for multi-threading, as (for example) a parent thread may iterate over
incidents
, while child threads iterate overlog_entries
. There should be an expectation that rapid requests from the child, causing HTTP 429, should not raise an exception in the parent thread iterator as it does today.The text was updated successfully, but these errors were encountered: