Caching is seemingly broken by React v18's Strict Mode... or is it cancellation?

[xml]

React 18 is a significant overhaul, and introduces new behavior in its during development, causing many, many consequences such as this. It double-renders components, in an attempt to show you whether your renderers are idempotent and free of side-effects. Nice idea, although it's breaking lots of brains. I don't in any way believe a-c-i needs to be responsible for React's idiosyncracies, although at a minimum, it would be nice for people to be aware of the risks. That said...

Like many folks, I made all my heaviest/slowest axios requests cancellable to deal with StrictMode, so that when the component is quickly unmounted and remounted, any initial data calls are aborted. I use the ES spec abortController, as described in Axios docs. So far, so good. It cut down dramatically on duplicate API requests during dev.

Until... I added axios-cache-interceptor, and discovered that it refused to cache any of my most important data calls, no matter what I did. This was a brain-bender, until I randomly tried disabling StrictMode. Boom: caching suddenly worked. Here's an example of the debug messages from a-c-i, before and after. You can see that the request ID is the same, but the outcome is very different... AFTER (working normally, for comparison):

{id: '578315523', msg: 'Sending request, waiting for response', data: {…}}
{id: '578315523', msg: 'Useful response configuration found', data: {…}}
{id: '578315523', msg: 'Found waiting deferred(s) and resolved them'}
{id: '578315523', msg: 'Response cached', data: {…}}

BEFORE (failing, in StrictMode)

{id: '578315523', msg: 'Sending request, waiting for response', data: {…}}
{id: '578315523', msg: 'Waiting list had an deferred for this key, waiting for it to finish'}
{id: '578315523', msg: 'Detected concurrent request, waiting for it to finish'}
{id: '578315523', msg: 'Deferred rejected, requesting again', data: undefined}
{id: '578315523', msg: 'Caught an error in the request interceptor', data: {…}}
{id: '578315523', msg: "Response not cached and storage isn't loading", data: {…}}

So: conclusion thus far: a-c-i is perhaps not necessarily optimized for the unique circumstances of StrictMode during DEV, and it'll work fine in PROD, which is what I'm most worried about. So, OK.

But... what if it's not actually StrictMode causing the problem, but something else related to it? My other calls are caching just fine, even in StrictMode. So, what if the problem is cancellable requests?

To test that, I re-enabled StrictMode, went to my most important data calls, and stripped the abortController. Huh. Whaddya' know?! Suddenly, caching works the way I'd expect: with the first request fetching new data, and the second just reading cache! Results:

{id: '578315523', msg: 'Sending request, waiting for response', data: {…}}
{id: '578315523', msg: 'Waiting list had an deferred for this key, waiting for it to finish'}
{id: '578315523', msg: 'Detected concurrent request, waiting for it to finish'}
{id: '578315523', msg: 'Useful response configuration found', data: {…}}
{id: '578315523', msg: 'Found waiting deferred(s) and resolved them'}
{id: '578315523', msg: 'Returning cached response'}
{id: '578315523', msg: 'Response cached', data: {…}}
{id: '578315523', msg: 'Returned cached response'}

Implication: adding an abortController to the requests is causing the issue. But... what if I leave the abortController there... but simply don't invoke it in useEffect? Once again: works fine, with an identical stream of debug messages as above. So, the problem isn't the abortController being present, but invocation of it.

(To be exhaustive: I happen to have an axios interceptor which does some routine error-handling for me. That interceptor returns errors as rejected promises. Could that be the issue? I disabled it. After that, caching still fails, and with the same debug signature. There's nothing else in the interceptor pipeline between axios and a-c-i.)

My hypothesis:

• we know that when axios cancels a request, it returns an error to the response interceptor pipeline, with a message of 'cancelled'.
• I haven't read the a-c-i source, but I think what's maybe happening is that: if a-c-i receives duplicate requests and one of them fails with an error, a-c-i refuses to cache the response to the other, successful request. This makes sense.
• However, does this make sense: a-c-i should filter out any errors related to a legitimate cancellation (those with a message of 'cancelled'), which would not only be more compatible with axios' expected behavior, but also have the side-effect of fixing the problem caused by StrictMode. ??
• Or, at a minimum: use the docs to advise people not to combine a-c-i with cancellable requests, as that will break things. a-c-i by itself will do a great job of catching and suppressing the duplicates, so let a-c-i take care of all that for you. Downside to this: getting duplicate responses is still generally a Bad Thing, even if you avoid burdening your API server with the duplicate requests. It often results in writing duplicate data to state managers, and is pretty hard to avoid. So... I'd suggest it's actually important to support both cancellation and caching, together, as "defense in depth."

Thank you for a great library. This is an edge-case here, and hard to predict. I hope this documentation of the situation is helpful to... someone.

[arthurfiorette]

Moved to #665