fix(deploy): distrust secret hash state without matching updateTime#1809
Draft
dqn wants to merge 2 commits into
Draft
fix(deploy): distrust secret hash state without matching updateTime#1809dqn wants to merge 2 commits into
dqn wants to merge 2 commits into
Conversation
…eTime The local hash state could suppress a needed secret update after the remote value changed out of band (a deploy from another checkout, or a console-side edit): the stored hash still matched the desired value, so the deploy skipped the update while the platform held something else. Secrets state now stores the updateTime returned by this deploy's own create and update responses alongside each hash (schema version 2), and a planned update is skipped only when both the hash and the remote updateTime match. Missing evidence — a v1 state file, an empty retried create response, or a platform that omits updateTime — always falls back to updating, never to skipping.
🦋 Changeset detectedLatest commit: d8700fd The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit: |
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.
Summary
A secret changed outside the current checkout (a deploy from another machine,
or a console-side edit) could be silently skipped by the next deploy whose
desired value matched the locally stored hash; the hash state now also records
the platform's
updateTimefor each secret and distrusts the hash when theremote timestamp no longer matches.
Behavior
updateTimeboth match the value listed from the platform at plan time.updateTimecomes from this deploy's own create/update response —never from a post-apply re-list, which could pair our hash with another
writer's timestamp.
file from an older SDK (schema v1), a retried create whose response was
synthesized empty, or a platform response without
updateTime.new state format (same values; no user action needed).
Verified against the platform
Create/update responses and list responses populate
updateTimeand agreeexactly (scratch workspace, deleted after). One caveat: the timestamp has
second granularity, so two writers hitting the same secret within the same
second remain indistinguishable — a platform-side generation counter or etag
would close that last window.
Notes
AuthConnectionhasno timestamp/version field. That path stays protected by the per-checkout
deploy lock (fix(deploy): serialize secrets state updates for concurrent deploys #1806) until the platform adds evidence.
fix/secrets-state-deploy-lock); will be rebased tomainonce that PR merges.