eth_blockNumber
(10 CUs), two eth_getLogs
(75 CUs), and two eth_call
(26 CUs) requests in the same second, you will have a total of 310 CUPS.Retry-After
Retry-After
header in the HTTP response. This indicates how long you should wait before making a follow-up request. We still recommend using exponential backoff since Retry-After
only accepts an integer number of seconds.429
response, and sending the request again, up to some maximum number of attempts you are willing to wait.random_number_milliseconds
seconds and retry the request.random_number_milliseconds
seconds and retry the request.random_number_milliseconds
seconds and retry the request.maximum_backoff
time.min(((2^n)+random_number_milliseconds), maximum_backoff)
, with n
incremented by 1 for each iteration (request).random_number_milliseconds
is a random number of milliseconds less than or equal to 1000. This helps to avoid cases in which many clients are synchronized by some situation and all retry at once, sending requests in synchronized waves. The value of random_number_milliseconds
is recalculated after each retry request.maximum_backoff
is typically 32 or 64 seconds. The appropriate value depends on the use case.maximum_backoff
time. Retries after this point do not need to continue increasing backoff time. For example, suppose a client uses a maximum_backoff
time of 64 seconds. After reaching this value, the client can retry every 64 seconds. At some point, clients should be prevented from retrying indefinitely.