Improve the "Pause the instance while "refresh logic" is running" section of the docs

Link to section: https://github.com/Flyrell/axios-auth-refresh#pause-the-instance-while-refresh-logic-is-running

The description of the pauseInstanceWhileRefreshing parameter is not really clear. At first glance, it seems that this parameter is needed to indicate whether requests should be queued if refreshing is already in progress, but this is not the case. We had to investigate the source code to understand whether we need to use this parameter or not. It would be great to add some use cases with description when and why it might be needed.

[Flyrell]

@guilliamxavier Sure, I see the point you’re making. What I mean by “no call” is to literally have no HTTP call inside it (I guess there was not a single use case for that 😅), but now when I think about it, it’s not useful anymore for whatever reason. The “no call” I mentioned does not make sense at all, as if there’s “no call”, the refreshing logic would never trigger an interceptor again - so, my bad.

TL;DR;

There is a couple of ways you can prevent the infinite loop right now:

1. use skipAuthRefresh in your refreshing call’s configuration

createAuthRefreshInterceptor(axiosInstance, failedRequest => {
    return axiosInstance.post('/', {}, { skipAuthRefresh: true }).then(/* ... */);
});

1. use different instance for your refreshing call

createAuthRefreshInterceptor(instance1, failedRequest => {
    return instance2.post('/', {}).then(/* ... */);
});

There’s not a single use case I can think of, that would need the pauseInstanceWhileRefreshing flag anymore.

---

The pauseInstanceWhileRefreshing flag was introduced in one of the first versions of the library (when there was no skipAuthRefresh flag) to prevent the instance from getting into the infinite loop (back then it was called skipWhileRefresh). It was ensuring that when the refreshingLogic is resolving, the library (specifically, response interceptor) would ignore any error originating from the instance provided in createAuthRefreshInterceptor (so that this logic is not called again as that error could have been the result of refreshing logic itself which would create the infinite loop). This might sound weird, but it was useful for a while, when the axios v0.19.0 was published and they’ve accidentally removed the possibility to pass the custom property into your request config. Fortunately, axios team did fix it in next versions, and I added the skipAuthRefresh flag to the library, which made pauseInstanceWhileRefreshing useless. After all, this is not useful anymore whatsoever, if you choose to implement the refreshing logic in one of the ways I mentioned above.

Back then I haven’t really think about using the second instance for refreshing as you suggested, and to be honest, it would definitely make more sense. I guess in the future versions I might even change ‘the API’, so that the library works more developer-friendly, as we can probably do a lot by working with multiple instances. We’ll see. However, thank you for taking your time and contributing.

[guilliamxavier]

After updating to v3.2.0 and testing a bit, I come to the conclusion that I must not use pauseInstanceWhileRefreshing: even without it I don’t see extra refresh calls (so it doesn’t seem useful), and with it the /bar and /qux failed requests are not retried after /foo (so it seems harmful)…