can't ever reset a signal once it's been aborted

[andycmaj]

the pattern i'm using here is a retry policy wrapped around a fetch request (using graphql-request).

i do not have the ability to re-define the fetch options every time i retry the request, as the fetch call is made internally in a dependency.

but i do have the ability to define the initial client.

inside the retry-handler, i planned on resetting the signal if timed out. but you can't currently do this as once a signal is aborted, it's aborted for good, and the map of aborted signals is module-private.

would you be open to exploring a reset API for these signals?

[andycmaj]

hey @mysticatea would you be open to accepting this change as a PR?

https://github.com/mysticatea/abort-controller/compare/master...asynchronous-dev:master

it isn't necessarily part of the standard... but is useful

[jaydenseric]

@andycmaj this package should not introduce anything non-standard about the AbortController global. Ideally, once all our environments have the standard AbortController global (modern browsers and recent Node.js versions already do) this package can be archived and we can safely remove it from our dependencies everywhere.

i do not have the ability to re-define the fetch options every time i retry the request

That is the root problem that needs to be solved, for a variety of reasons other than the abort controller. What if your fetch options had an authorization header for the first fetch, but before the second fetch is attempted the user logs out. The API design of a data fetching library needs to allow fetch options to be determined at the time of actual fetch.