Stream resuming fails after tab changes

[justinbelcher]

Versions

• Client: 1.1.4 (via electric-db-collection 0.2.1)
• Electric: version 1.2.4

Bug description
Electric tanstack-db collection fails to resume after changing tabs n=2 times. It does not need to be rapid. Changing back a third time causes the stream to resume, strangely.

I did not observe any logged errors. We are using an authenticated fetch client and onError handlers (which retry w/ auth) in tanstack-db electric ShapeOptions.

Pictured: hung state after second tab change (w/ patched-in logging). tanstack-db optimistic mutations fail after timeout.

Expected behavior
Stream resumes consistently (or we have additional options to control resume behavior)

Note

The fix in #3431 does not appear to address this issue for me.

[justinbelcher]

Working theory: Backgrounding the UI aborts the current long‑poll with reason pause-stream (expected, resumes on return), but the client treats the abort as fatal and throws. A second occurrence of this abort during backoff causes the FetchBackoffAbortError to bubble out of the #requestShapeLongPoll loop, killing the steam until something kicks if off again (like a third tab toggle).

Possible fix: try/catch the long-poll fetch in #requestShapeLongPoll and return as expected (instead of throw) when requestAbortController.signal.aborted is set or error is a FetchBackoffAbortError. This seems to work for me but I'm not 100% on the implications of such a change.

[justinbelcher]

Perhaps related to #3566 ?

[tec27]

So this seems to be an issue with PrefetchQueue, what seems to happen is that if you abort requests immediately after resuming from a pause (by hiding the page), the PrefetchQueue ends up storing a request for a URL that will also be the request that is made when the page is made visible again. The PrefetchQueue is only cleared out/reset in the case that there are further chunk URLs to prefetch, so if there aren't (as is often [always?] the case here), you end up with a PrefetchQueue with only already-aborted requests in it that appears to be able to serve the next resume.

The abort errors that PrefetchQueue uses are never intended to be handed to its callers, and in the typical cases, they never are (so ShapeStream never expects to handle them, it thinks any aborts it sees that it didn't explicitly make must come from the ShapeStream's options signal, and thus the ShapeStream should be considered dead). This path, however, results in PrefetchQueue returning a Promise that will directly throw that abort error as soon as it is awaited, and ShapeStream awaits it.

The fix is a pretty small change (feel free to take this if you think it makes sense, might be easier than me making a PR for it :) ):
tec27@9987912