The "recovery pattern" in the docs incompatible with live queries

[samwillis]

This recovery pattern in the docs:

Clean up collections in error states:

if (todoCollection.status === "error") {
  // Cleanup will stop sync and reset the collection
  await todoCollection.cleanup()
  
  // Collection will automatically restart on next access
  todoCollection.preload() // Or any other operation
}

https://tanstack.com/db/latest/docs/guides/error-handling#collection-cleanup-and-restart

Is incompatible with having an exiting live query on the collection, it will throw a warning and the live queries will not recover.

We should look how to ensure you can restart an errored collection without it breaking live queries - options:

1. make the restart pattern softer with a new forceRestart that does one of:

• internally truncates and resyncs - this should be compatible with live queries, but may not clear all state.
• send a signal to also restart live queries that are attached to the collection.

2. Chang the implementation such that a live query can be attached to a "cleaned up" collection that is then restarted and when it is would restart the live query. We can continue to emit the warning, but change it to indicate that the live query will not be updating as one of its sources is cleaned up.

Discussion on Discord: https://discord.com/channels/719702312431386674/1443598939331887238

[hedblad]

We recently migrated to TanStack DB in production and are running into scenarios where we need to recover and ensure everything is fully caught up. We’re using it with ElectricSQL, and we sometimes end up in states where sync is not running.

For example, when we get a TimeoutWaitingForTxIdError, the “optimistic” state is cleared but the corresponding change has not actually synced yet. From the user’s perspective, their change appears to be undone after the timeout has been hit. This happens multiple times per day for us and results in a very poor UX.

Right now our only option is to ask the user to reload the page (we’re considering forcing a reload, but that’s not a great experience either). After a refresh, the change is back and sync is running again.

Having an API/primitive to restart all shapes and ensure they are fully caught up would help us a lot here!

[KyleAMathews]

@hedblad this sounds like a bug that we should fix! Have you managed to reproduce this yourself or only users have observed it? The two options for what's happening that occurs to me off-hand is perhaps the txid is wrong sometimes e.g. you don't query it within the same transaction.

If you do have a good reproduction, please let us know everything you know about the issue — this has to just work and be rock solid.