Error handling with Replicache

[paulshen]

In course of working with Replicache, I ran into a situation on my phone where my app stuck in a state which indicated useSubscribe not successfully running the query function (stuck on default value). I'm unable to repro now but it got me thinking about error handling and how to handle these situations gracefully.

I tried messing with IndexedDB to put it in a corrupted state. I got some console messages but to handle these, I had to set the onError on a subscribe call. My app was only using the React useSubscribe hook, which does not expose errors. I'm treating any subscribe - onError as an irrecoverable error, showing the user a "uh oh" message and a button that deletes IDB database and reloads page.

It'd be good to know when Replicache gets wonky and how to recover from it so the app is not stuck in a bad state.

Potential action items

• Document possible Replicache errors and actions for each
  • eg What happens with bad mutations? What happens if mutation ID is off?
• Expose a global error handler (maybe replicacheClient.onError)
• Have a story how to recover from a bad Replicache state
  • Expose an API to reset Replicache state (delete KV store)
  • Maybe expose an API to query if there are pending mutations? If no pending mutations, could more aggressively destroy local state

[aboodman]

Triaging bugs. I think all three of these are still excellent ideas.

[aboodman]

Some other examples that have come up recently:

• We wake up from sleep and find that the client-side state has been GC'd
• Server returns saying that server-side state has been GC'd
• license check fails

We seem to need some consistent philosophy for how asynchronous errors should get handled. I like Paul's proposal:

Replicache.onError

where the default impl is to throw and assume caller has a window.onerror if they care about this.