[YarnSaw]

Addresses #37.

Used request && rather than optional chaining since I vaguely recall backwards compatibility being important, and optional chaining was only introduced in node 14.

[mjwwit]

Thanks for finding this and spending time on creating the fix.

However, this only prevents the null dereference, but the error handler still processes errors from aborted requests. If the same XHR is reopened and sent before the old request emits its error, request points to the new request, so the null check passes and the old error can corrupt the new request’s state or trigger an incorrect retry.

Could we associate the handler with its originating request and ignore errors from aborted or superseded requests before retrying or calling handleError? Please add regression coverage for aborting a pending request and immediately reusing the same XHR.

[YarnSaw]

I see I broke node 13 compatibility on my new regression test, I'll fix that.

Also not 100% happy with my most recent commit, realized after that if a new xhr.open is called after the abort it'll still break. I'll undraft the PR once that's fixed.

[mjwwit]

I'm quite far into a full refactor of the entire project and that will definitely fix this problem. It will be released as a major version, so I'd not spend too much time on this unless you'd like me to release it as a patch on the current major.