-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How should the "unavailable" status interact with network adapter startup? #155
Comments
Interesting. I would say the second option is preferable to an arbitrary timeout. Or at the very least have some way of exposing to users that the network is not ready before they request a document. I would have thought that the current implementation does commence sync for an unavailable doc automatically when a new peer connects. If not, I would say it should anyway? |
We can implement beginning sync for an unavailable document when a new peer connects quite easily. Right now that would still be an awkward API though I think because it sort of makes the "unavailable" status less useful. In the snippet above the user would have to always wait on I think instead having a kind of "network ready" state for the whole repo might be what is required. That way the user waits for "network ready" and then if a document is unavailable they know that it's not down to the network waiting to come up. |
I've been fighting with this a little bit lately. In trail-runner network connections can come and go in the frontend as ServiceWorkers get replaced. My solution right now is to block on calling find until I've set up a network connection but I don't think this is necessarily the best approach. I think the issue here is that "network ready" isn't monotonic (your network might report being online prematurely or might go offline again as you travel through a tunnel) and also you may already have all the data you need locally. In TEE, @geoffreylitt uses a loading screen to guard against trying to do things before connecting. I don't think that's quite the right approach either but it suggests there may be options here. One thing I've been meaning to do for a while is to start exposing some kind of explanations for why a document didn't load. Was it that there were no peers, that there were peers but nobody would give you the document, was the file corrupted, or was it a bogus input? So many ways to fail. |
Consider this snippet:
This will always create a handle which is unavailable, regardless of whether the sync server actually has the document. When we call
repo.find
theBrowserWebSocketClientAdapter
is still in the process of connecting and so theRepo
has no peers. Having no peers and not finding the document in storage theRepo
marks the handle as unavailable. Later, the websocket network adapter finishes setting up the connection, but by then the handle is already marked as unavailable and so we don't send a sync message to the newly connected peer for the document in question.I'm not sure what the solution should be here. Here are a few options which occur to me:
The text was updated successfully, but these errors were encountered: