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
{{ message }}
This repository has been archived by the owner on Apr 18, 2024. It is now read-only.
if CID fails due to context timeout, the next time it is requested, instead of timeout of 19s and 3 retries, spend full 60s on a single fetch to get some timeouts over the finish line.
As we transition to backend requests for variable-sized car files, we can potentially expect a common pattern of a head request to precede full requests, and that may help us understand the expected characteristics (and size) of the full request as well.
The text was updated successfully, but these errors were encountered:
Given we now deal with variable-length CAR responses, we need more than a naive time bound how logn entire HTTP request should take.
We need dynamic timeout based on the time we've received new bytes (or new block) from L1.
CAR fetch could take 30 minutes, but if after 2 minutes it stalls and stops sending me new bytes, I want to timeout after 1 minute, and not wait 28m until global request timeout kicks-in.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
@lidel suggests:
As we transition to backend requests for variable-sized car files, we can potentially expect a common pattern of a
head
request to precede full requests, and that may help us understand the expected characteristics (and size) of the full request as well.The text was updated successfully, but these errors were encountered: