useFetcher - only some requests are cancelled after interuptions

[jmlee2k]

I've just started exploring Remix, so I fully understand that I may have got this wrong, but I expected that Remix would cancel all stale fetch requests when initiating a new one.

I've created a simple test case to show the issue:
https://stackblitz.com/edit/node-yp8gvx?file=app%2Froutes%2Findex.tsx,app%2Froutes%2Fchars.tsx

It uses useFetcher to make a call to resource route every time the text in the input box changes. I've added an artificial 4s delay to the loader on the resource route to clearly show what's happening.

When I type "homer" in the search box, 5 search requests are sent, which makes sense:

1. "h"
2. "ho"
3. "hom"
4. "home"
5. "homer"

I would expect that the first 4 fetches would be cancelled, since the following one would interrupt it (assuming all were typed within the 4s delay), however, it looks only some of the requests are cancelled:

If I type "this is a test", it looks like every other request is cancelled:

Am I missing something here?

Thanks in advance!

[machour]

Is your backend fulfilling those requests ? (We're missing an interesting part of your screenshot with requests times)

[jmlee2k]

I've made a repo with the test case and ran it both locally and in stackblitz.

I've included both the chrome devtools screenshots and the dev server output. The results are slightly different (I assume due to the fact that stackblitz runs via a service worker), but both show that some stale requests aren't cancelled.

Local

GET /search?q=h&_data=routes%2Fsearch - - - - ms
GET /search?q=hom&_data=routes%2Fsearch - - - - ms
GET /search?q=ho&_data=routes%2Fsearch 200 - - 4007.767 ms
GET /search?q=home&_data=routes%2Fsearch 200 - - 4014.332 ms
GET /search?q=homer&_data=routes%2Fsearch 200 - - 4017.660 ms

Stackblitz

https://stackblitz.com/github/jmlee2k/remix-usefetcher-test

GET /search?q=h&_data=routes%2Fsearch 200 - - 4009.955 ms
GET /search?q=ho&_data=routes%2Fsearch 200 - - 4010.095 ms
GET /search?q=hom&_data=routes%2Fsearch 200 - - 4003.055 ms
GET /search?q=home&_data=routes%2Fsearch 200 - - 4010.225 ms
GET /search?q=homer&_data=routes%2Fsearch 200 - - 4010.725 ms

[jmlee2k]

I've also tested this using @kentcdodds informative full stack components article (which is essentially a fully-realized version of this test case), and I'm getting similar results after adding an artificial delay.

[melodyclue]

Have you found a solution?