Better Timeout Handling about automerge-repo HOT 5 OPEN

I talked this over with @alexjg earlier today and I think what we want is something roughly like the following:

• DocHandle should have a queryable DocumentState which is (for now) "OPENING", "READY", "DELETED" or "FAILED".
• OPENING and FAILED either have "reasons" or "substates" or some such concept: FAILED might be a bad document ID (INVALID_URL) or no/weak network connection leading to timeout (NO_SOURCE).
• In the future, FAILED should have retry logic if new peers come along
• In automerge-repo-react-hooks, useDocument should also return the DocumentState (third argument?) and we should implement an example which allows the user to differently render OPENING (download progress?), READY (normal) and FAILED (recovery suggestions: connect to network, check URL, etc).
• DELETED just comes along for the ride here but one can imagine an undelete which might re-request the document from peers.

from automerge-repo.

Continuing to make notes to self here: we could use a global/shared progress timeout that resets if any data comes in for any document so that documents don't timeout when they're in a queue awaiting their turn.

from automerge-repo.

@acurrieclark i added a FAILED state that we transition to { after: this.#timeoutDelay } and the tests... seem the same. I think I need some other kind of test here but I'm not exactly sure what it is. Probably we should start exposing the DocumentState.

from automerge-repo.

Okay, I have exposed the current state's name and test that we do enter "failed". I think we can build on this but this is an improvement. I'm going to try and finish an Automerge URL patch today so that I can go into the weekend with a clear conscience.

from automerge-repo.

We discussed this just now and agreed that timeouts should have the same behaviour as "unavailable" (not an error, return undefined.)

from automerge-repo.