-
-
Notifications
You must be signed in to change notification settings - Fork 14
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
Epic: Concurrent updates may overwrite each other #494
Comments
SDK: oddsdk/ts-odd#163 |
Small question: How would the API for a destructive update (i.e. "OVERWRITE" capability) then look like? |
🤩 🤩 🤩 🤩 🤩 sorry :D |
It depends on what you mean by "destructive". Since WNFS is nondestructive by default, removing a file doesn't actually get rid of it, since it's still in history and can be recovered. So a history-preserving deletion is an If we're finding these specific words are confusing now that we have actual experience with this system, we could move to more WNFS-specific terms like |
Reproduced By
Environment
All of them
Ruled Out
Root Cause
Updates may not know about changes from concurrent updates.
Solution
We need both of the following, though the SDK is prior in the critical path:
Web API
Web API should perform structural validation on updates, and reject updates that drop files. This will then be passed back as a 422 to the client along with the current CID.
SDK
SDK needs to be able to do a merge operation on its changes versus a new WNFS HEAD. When the server rejects an update, get the new CID and rebase the local changes on this. This will change the content of each diff, since at minimum you must bring any new files along. Atomic actions (coming) improve on this further by allowing arbitrary sub-file reconciliation.
The text was updated successfully, but these errors were encountered: