Repository navigation
fix: a fallback whose first identity is being saved is still admitted - #420
Merged
Merged
Conversation
A profile-triggered recovery can publish a fallback's first UUID between the host snapshot and the coordinator's pre-join read. Exact binding admission then dropped the fallback as row-ineligible, returning the main provider 400. A second window exposes a torn state/config row at that same read. Join recoverable same-epoch pool writes with the existing bounded budget, then adopt only a first identity whose store, row and epoch still match. Keep all admission exclusions and exact-version proof checks, and preserve the branded transient error when the writer cannot finish. Both race windows have red-first Core regressions and CAUGHT named mutation controls with Core broad settings. Existing history tests are unchanged. Pinned Bun 1.3.14 Linux loops: main originally had 2/40 single and 3/40 block status-400 misses; v2.1.2 had none; fixed loops have none in 40+40 processes, with one unrelated default-deadline timeout in each. Core owning file: 122 pass. Final OpenCode owning file: 304 pass, two claude-prime timeouts on the shared runner. Core/OpenCode typechecks, scripts typecheck, lint and formatting pass.
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
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 by the 2.2.0 release PR's CI. A request could skip a fallback account whose identity was being saved for the first time and return the main account's error instead: the request had captured the account's binding before the identity existed, and authorization then found the same row with the identity set (or caught a partly written state/config pair) and refused it as
row-ineligible. 2 of 40 runs of the affected test on main, 0 of 40 on v2.1.2; the change in cause-keyed refresh joining (#414) stopped serve requests from waiting on that publication.Red-first Core regressions for both windows; mutation rows
serve-adopts-concurrent-first-identityandserve-joins-concurrent-first-identity-writeCAUGHT. After the fix: 0 status-400 misses in 40 + 40 Linux runs. No changelog line: the bug isn't in any release.Summary by cubic
Fixes a race that let a serve request skip a fallback account whose first identity was being saved, returning the main provider's 400 instead.
Written for commit a6efa38. Summary will update on new commits.