[WRONG BRANCH] fix: prevent Codex refresh lock ownership races - #175
[WRONG BRANCH] fix: prevent Codex refresh lock ownership races#175luvs01 wants to merge 1 commit into
Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
This pull request currently targets @luvs01 Please retarget this PR to Its title has been prefixed with This pull request is being kept as a draft automatically. Once every issue above is resolved, it will be marked ready for review again. |
📝 WalkthroughWalkthroughThe refresh-lock flow now protects empty locks during initialization and verifies device/inode identity before cleanup. Tests cover waiting for an external refresh and preserving a replacement lock file. ChangesRefresh lock race handling
Estimated code review effort: 2 (Simple) | ~15 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/codex/account-store.ts`:
- Around line 330-336: Make refresh-lock removal atomic with ownership: in
src/codex/account-store.ts lines 330-336, replace the boolean stale-check flow
with an atomic mechanism that reclaims the inspected lock without returning a
result that callers later unlink by pathname; in lines 372-382, replace the
statSync(path)/unlinkSync(path) release sequence with the same owner-bound
removal mechanism, since a second identity check does not close the race. Add a
regression test that replaces the lock after identity validation and before
removal, verifying the replacement lock is preserved.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: dd8eba7d-e586-4b2b-9e3c-66291920bd1c
📒 Files selected for processing (2)
src/codex/account-store.tstests/codex-account-store.test.ts
| // A newly-created lock is briefly empty while its owner writes metadata. | ||
| // Do not let a waiter steal it during that acquisition window. | ||
| try { | ||
| return Date.now() - statSync(path).mtimeMs > REFRESH_LOCK_STALE_MS; | ||
| } catch { | ||
| return false; | ||
| } |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | 🏗️ Heavy lift
Make refresh-lock removal atomic with lock ownership.
Both paths validate a lock and later remove path by pathname. Another process can replace the path in that interval. The subsequent unlinkSync(path) then deletes an active replacement lock.
src/codex/account-store.ts#L330-L336: Change stale-lock reclamation so the inspected stale lock is reclaimed atomically. Do not let the caller unlink a path from a boolean stale result.src/codex/account-store.ts#L372-L382: Replace thestatSync(path)thenunlinkSync(path)release sequence with an owner-bound release mechanism. A second identity check cannot close this race.
Add a regression test that replaces the lock after identity validation and before removal.
📍 Affects 1 file
src/codex/account-store.ts#L330-L336(this comment)src/codex/account-store.ts#L372-L382
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/codex/account-store.ts` around lines 330 - 336, Make refresh-lock removal
atomic with ownership: in src/codex/account-store.ts lines 330-336, replace the
boolean stale-check flow with an atomic mechanism that reclaims the inspected
lock without returning a result that callers later unlink by pathname; in lines
372-382, replace the statSync(path)/unlinkSync(path) release sequence with the
same owner-bound removal mechanism, since a second identity check does not close
the race. Add a regression test that replaces the lock after identity validation
and before removal, verifying the replacement lock is preserved.
Motivation
openSync("wx")and only then writes JSON metadata, becauseisRefreshLockStale()treated any read/parse error as immediately stale.Description
mtimeis recent, so a just-created but not-yet-written lock cannot be classified stale immediately (addedstatSyncusage inisRefreshLockStale).fstatSync(fd)and only unlink the lock on release if the current path identity (statSync(path)) matches the held descriptor (comparedevandino) to prevent deleting a replacement lock.fstatSync/statSyncand the conditional unlink/ownership check inwithCodexRefreshFileLockinsrc/codex/account-store.ts.refresh does not steal a newly-created empty file lockandrefresh owner does not remove a replacement file locktotests/codex-account-store.test.tsto exercise the initialization and replacement races.Testing
bun test tests/codex-account-store.test.ts— the updated account-store test file ran and all tests passed (25 pass, 0 fail).bun run typecheck— TypeScript typecheck completed successfully.bun run privacy:scan— privacy scan completed successfully.bun run test— a full-suite run was attempted but the repository contains unrelated, pre-existing authentication test failures and long-running timeouts that prevented a green full-suite result; the focused regression and static checks above are green.Codex Task
Summary by CodeRabbit