Prevent duplicate first-run setup - #1997
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughSetup completion now claims setup state in a guarded transaction. Concurrent requests receive a specific error, while the winning request creates the owner and settings atomically. ChangesSetup concurrency control
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
e4d7e50 to
1a8f225
Compare
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
@coderabbitai full review |
✅ Action performedFull review finished. |
What changed
First-run setup now claims the setup state inside the same database transaction that creates the owner account and stores the keys. If another setup request finishes first, the later request fails closed and leaves the existing owner and keys in place.
I also added a regression test that submits two setup forms at the same time and checks that only one owner is created.
Why
Two setup requests could both see that setup was not complete before either one wrote the final setup state. Both requests could then create owner and key state, and the later request could replace the keys.
Checks
nix develop -c deno task test:files test/integration/server/setup-concurrency.test.ts test/integration/server/setup.test.ts test/shared/db/settings.test.tsnix develop -c deno task precommitSummary by CodeRabbit
Bug Fixes
Tests