-
Notifications
You must be signed in to change notification settings - Fork 0
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
no longer clone body + package upgd and fix tests #14
Conversation
8600110
to
8bbc7ee
Compare
userSignalHandler = arg => abortController.abort(arg) | ||
userSignalHandler = () => { | ||
abortController.abort(new Error('AbortError')) | ||
} | ||
userSignal.addEventListener('abort', userSignalHandler, { | ||
once: true, | ||
}) |
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.
Let's simplify it a bit:
- Don't throw if our signal is already aborted, let Undici do this so that we'll be sure we don't override the default behavior.
- Ensure you always pass the abort reason from the original signal.
Inspiration: whatwg/fetch#905 (comment)
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.
let Undici do this
We should just ensure in default retry function that we don't retry on AbortError as it makes no sense
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.
We should just ensure in default retry function that we don't retry on AbortError as it makes no sense
Actually if we timed out then I think we want to retry? And the timeout would cause an Abort Error. Perhaps it would make sense to also set state.options.retry = 0
if the request was aborted by the user?
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.
And the timeout would cause an Abort Error
I don't think so. New Undici throws the abort reason as-is, so now aborts caused by timeouts should immediately throw TimeoutError.
You can test it by pasting a following to REPL:
const { fetch } = require("undici");
class CustomError extends Error {
constructor(message) {
super(message);
this.name = "CustomError";
}
}
let ac = new AbortController();
ac.abort(new CustomError("foo"));
await fetch("http://example.com", { signal: ac.signal }).catch(console.error);
ac = new AbortController();
ac.abort();
await fetch("http://example.com", { signal: ac.signal }).catch(console.error);
It also means that you can get rid of fragments like this, since we will get the actual error anyway with no need of detecting it:
if (error.name === 'AbortError' && state[STATE_INTERNAL].timedout) {
// eslint-disable-next-line no-ex-assign
error = new TimeoutError(state[STATE_INTERNAL].timedout, state)
}
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.
Hmm I made the changes but as you'll see in the tests, many of the Timeout Errors now became Abort Errors. So not sure if Undici is passing Timeout Error
into the abort.
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.
Ok, my previous message is solved by upgrading undici to 5.23.0
75f4b32
to
0752c39
Compare
0752c39
to
c792846
Compare
c792846
to
75313d3
Compare
No description provided.