feature request: conflict detection for `op item edit` through compare-exchange primitive

Options
cschwarz
cschwarz
Community Member
in CLI

Suppose the following sequence:

  • op item get
  • inspect the item, decide to make some changes
  • op item edit

If two clients perform this sequence concurrently, then currently, the last op item edit will silently overwrite the other client's edits.

Instead of silent overwrites, it would be nice to have a compare-exchange-like mechanism.

For example:

op item get --format json returns the item version already.
Add a flag to op item edit to supply that version number, to express causality of the edit.
Like, op item edit --base-version THE_VERSION_NUMBER_FROM_GET .
If the on-server version doesn't match the client's version, the edit should fail.
The client can then get the item again and start over.

Same for documents, which are my primary use case, actually.

Example flow:

op item get omfwcxlo3llaktwy5tbah5wx4a
ID:          omfwcxlo3llaktwy5tbah5wx4a
...
Version:     1
Category:    DOCUMENT
Files:       untitled-file (554 bytes)

First edit succeeds

echo "client 1 edits" | op document edit omfwcxlo3llaktwy5tbah5wx4a --base-version 1`

(item version on server is now 2)

Second edit fails

echo "client 2 edits" | op document edit omfwcxlo3llaktwy5tbah5wx4a --base-version 1`  
CONFLICT: item version on server is 2, but client-provided base-version is 1

Trade-offs

Obviously this requires the 1Password service to be authoritative about the versions.
And the flow assumes an online edit workflow.
But I think that's the case already.

Side Note

This primitive can also be used for idempotency, although, I think idempotency is less interesting for 1Password.

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Browser:_ Not Provided

This discussion has been closed.