Skip to content
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

Open
3 of 5 tasks
expede opened this issue Apr 15, 2021 · 4 comments
Open
3 of 5 tasks

Epic: Concurrent updates may overwrite each other #494

expede opened this issue Apr 15, 2021 · 4 comments
Assignees

Comments

@expede
Copy link
Member

expede commented Apr 15, 2021

Reproduced By

  • Brooke
  • Boris
  • Philipp
  • James
  • Brian
  • Daniel
  • Steven

Environment

All of them

Ruled Out

  • IPFS Cluster
  • DNS
  • Application code
  • Web API
  • SDK

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.

@expede
Copy link
Member Author

expede commented Apr 15, 2021

SDK: oddsdk/ts-odd#163

@expede expede changed the title Epic: Concurrent updates may lead to dropped files Epic: Concurrent updates may overwrite each other Apr 16, 2021
@matheus23
Copy link
Member

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.

Small question: How would the API for a destructive update (i.e. "OVERWRITE" capability) then look like?
Will the server check whether the UCAN has overwrite capabilities? I think the client should be able to choose whether the server should reject changes that overwrite.

@matheus23
Copy link
Member

Atomic actions (coming) improve on this further by allowing arbitrary sub-file reconciliation.

🤩 🤩 🤩 🤩 🤩

sorry :D

@expede
Copy link
Member Author

expede commented Apr 22, 2021

Small question: How would the API for a destructive update (i.e. "OVERWRITE" capability) then look like?

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 APPEND. To actually delete something, you need to rewrite history, so OVERWRITE is higher permission required.

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 REWRITE_HISTORY (or RETCON 😉).

@expede expede self-assigned this Apr 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants