-
Notifications
You must be signed in to change notification settings - Fork 7
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
Request for documentation clarification around fn request_document
#22
Comments
This |
That is the right answer.
When a document has been successfully requested, it will also be persisted via the storage API. I've added an assertion for this in our test suite, see b8f69d7 Note that this happens concurrently to Agree on the need for documentation. |
Thanks! That test matches my experience yesterday. I was exiting my program immediately after request_document was awaited. The I don't have an obviously-better idea than that, but the first thing that sticks out at me is that maybe a document ID could be the uuid of the first transaction instead of pre-generated. Then you know you at least have the first head in common if you start syncing? |
It's an interesting idea, for now we do not sync a locally created document until it has been edited. See |
And as discussed, this is solved by calling |
Writing an issue I had while integrating, may follow up with a PR as I continue.
If
request_document
is awaited, does that suggest that the document is fully syncronized at-time-of-return or does it mean that the sync with your repo has been acknowledged or something else?The text was updated successfully, but these errors were encountered: