-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Retry certain requests on failure #4015
Conversation
New baseurl check output in run mode:
|
- swap out passthrough’s for pumpify / duplexify / pump - clean up error handling / messaging / retry logic
…wait for first head bytes
- ensure debug messages are consistent between request streams + promises - set static constants
- keeps the debug logic identical between promises + streams - ensures all logic paths are also consistent - consolidates the pop’ing of intervals in a single place
… recursive lookup
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- didn't get a chance to clean up some of the retrying proxy stuff in the
packages/agent
but otherwise LGTM!
Hey @flotwig / @brian-mann , I just pulled this commit into my fork whilst testing microsoft edge and I can't load any browsers now in gui or cli mode, I get the error in the terminal output below. Just removed pulling master into my fork (this pr and it has resolved it for all browsers, just a friendly fyi 👍 I am running a mbp 2018 with mojave 10.14.4
|
@YOU54F try deleting all of the .js files from packages/network/lib, you have an old version of a TS file transpiled |
Spot on @flotwig , sorted it, thank you for that! |
Closes #4013
Closes #898
Closes #1013
Closes #4232
options.retryOnNetworkFailure
istrue
(default) or it's a Cypress proxy request,ECONNREFUSED
,ECONNRESET
,EPIPE
,EHOSTUNREACH
, andEAI_AGAIN
errors will be retriedoptions.retryOnStatusCodeFailure
istrue
, requests will be retried on non-successful status codesECONNREFUSED
retries and proxied retries happen at shorter intervals: 0s, 100ms, 200ms, 200ms{ timeout: null }
on proxied requests so the only timeout is the eventual OS timeout, since Chrome won't timeouthttps-proxy
connections in proxied mode and in direct mode using same rulesbaseUrl
check inrun
mode at 0s, 1s, 2s, 2s intervals, then fail if it is unsuccessful