Feature: Timeout, Retry, and Queue about frisbee

[niftylettuce]

Just FYI I already implemented timeout and retry locally. Just need to push it up. I definitely need some help with tests.

[niftylettuce]

I pushed my work in progress by the way at 38d2252 if anyone wants to help out with it.

I would love help writing tests for it. Timeouts/retries all need tested.

[niftylettuce]

Yeah @antgel, you would be able to refresh JWT token in retryFn.

@akmjenkins I'll gladly award you the bounty if you can open a PR for this https://github.com/niftylettuce/bug-bounties/issues/5

[niftylettuce]

Also, per #92 we should allow a custom callback function to be called on retries, which would allow JWT refresh tokens to be updated for example.

[akmjenkins]

My fetch-retry approach was to leave it entirely up to the user (no opinions based on server response codes). It could be passed into a base frisbee instance or individual requests. The API was pretty straightforward:

{
    retries: number of times to retry,
    retryOn: [array of status codes],
    retryFn?: async function to execute between each retry
    retryTimeout?: ms to wait in between retries (sensible default - like 1000ms, ignored if retryFn is supplied)
}

The only tricky parts were those you pointed out - don't retry if the AbortController.signal.aborted === true

The retryFn was especially helpful because it allows the user to do absolutely anything they want (like refresh JWT) in between retries.

Would an API like this work?

[niftylettuce]

I like the simplicity of that - but I think that you could eliminate retryOn and have that logic be up to the user in retryFn. Then we could make a default retryFn that checks against isRetryAllowed was true OR if status code was 429, 502, 503, or 504, AND ALSO checks against the Retry-After header if it existed.

[antgel]

Great to see the activity around here! :) I don't mind that #86 was closed in favour of this, but does the above issue description include relevant details to handle that scenario? (Retrying a request after refreshing JWT access token.)

[antgel]

Oops, I missed it, it was in #92 (comment). :)

[niftylettuce]

We should also use https://github.com/sindresorhus/p-queue to create a queue of requests that can be processed.

[niftylettuce]

What's left:

• Write tests for timeout
• Write tests for retry
• Try to get 100% code coverage
• Any instance of polyfill.io need to have proper listing of polyfills (e.g. 38d2252#diff-eacf331f0ffc35d4b482f1d15a887d3bR15 is empty right now)
• Ensure timeout, retry, retryStatusCodes, retryMethods, retryAfterStatusCodes, handleRetry are documented
• There is a queue option I added but it's not being used, so either remove that or add support for queue (e.g. via https://github.com/sindresorhus/p-queue)