Repository navigation
fix(editor): a failed secret save no longer duplicates the new object - #613
Merged
Merged
Conversation
Creating a host, key or identity stores the object first and its secrets second. When a secret failed to store, the save threw before the editor learned the new object's id, so it stayed in "create" mode and every later autosave created the object again. The three form saves now announce the created object before storing its secrets, through a required callback. The editor switches to editing on that call, so the next autosave updates the same object and retries its secrets. The shared create-then-store step lives in createWithSecrets. Refs #608
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found while working on #608 / #611.
Problem
Creating a host, key or identity stores the object first and its secrets second. When a secret failed to store — a refused or unreachable team vault upload, or a local store error — the save threw before the editor learned the new object's id. The editor stayed in "create" mode, so every later autosave created the same object again.
The #608 case reaches it directly: a new team host with a knock sequence on a server too old for it is created, the sequence is refused, and the next keystroke creates a second host.
Change
saveHostFromForm,saveKeyFromFormandsaveIdentityFromFormtake a requiredonCreatedcallback and call it as soon as the object exists, before storing its secrets. All six callers (desktop and mobile) switch to editing from that callback instead of from the return value, which is gone. The next autosave then updates the same object and retries the secrets that are still dirty.The create-then-store step the three saves shared is now
createWithSecretsinvaultObjectSecrets.ts.Tests
New cases in
hostForm.test.tsandkeychainForm.test.ts: a new host, key and identity whose secret store rejects are still announced; an edit announces nothing. Watched them fail before the change.tscand the services, stores, hosts, keychain, mobile and connections suites pass locally. No live run.Not changed
Mobile edit screens still show no error when a save fails; the object is no longer duplicated, but the failure is silent there.