fix(update): preserve the agent pin on a failed resolution, and close a JIT-upgrade race - #711
Merged
Merged
Conversation
… a JIT-upgrade race Two findings CodeRabbit raised on PR #710 (real, but unrelated to #707, since that PR's branch had been based on a stale pre-squash-merge history that made them look like part of its diff - they are not; the branch has since been corrected): - bin/agentbox's resolve_agent_pin() returned the mutable channel URL itself on a failed resolution (network error, or a redirect that did not land on a nixpkgs release). The caller wrote that straight into the pin file, silently downgrading a good immutable pin to the mutable channel URL on nothing worse than a transient blip - and that write survives an otherwise-successful update, since it is not part of what a failed update rolls back. resolve_agent_pin() now returns None on failure and the caller skips write_agent_pin() entirely, leaving the existing pin alone (matching what the OSError handler already did for a write that failed outright). - modules/src/lib/agents.sh's agent_upgrade() read the recorded pin and decided "already at this box's pin" BEFORE acquiring the per-harness flock, not after. Two concurrent upgrades for the same agent (the update service loops over every user; a person can run this by hand at the same moment) could both pass that check before either took the lock; if the second one's own `nix profile add` then failed, its recovery path restored what it still believed was the previous pin, silently undoing the first process's already-successful upgrade. Moved the pin read to right after the lock is acquired, matching how agent_install() already re-checks its own condition once it holds the lock ("The winner of the race installed it while we waited; nothing to do."). Both are one-line-of-logic fixes with no design trade-off, so this goes straight to a PR rather than an issue, per AGENTS.md. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MB26GQRXxhfGYoxWTsUp6M
|
Warning Review limit reachedNext included review available in 37 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (5)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
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.
Summary
Two findings CodeRabbit raised on PR #710, real but unrelated to #707 (that
PR's branch was briefly based on stale, pre-squash-merge history that made
these look like part of its diff - they were not, and the branch has since
been corrected to a clean rebase onto master).
bin/agentbox:resolve_agent_pin()returned the mutable channel URLitself when resolution failed (network error, or a redirect that landed
somewhere unexpected). The caller then wrote that straight into the pin
file via
write_agent_pin(), silently downgrading a good immutable pin tothe mutable channel URL on nothing worse than a transient blip - and that
write survives an otherwise-successful update, since it isn't part of what
a failed update rolls back. Now returns
Noneon failure, and the callerskips
write_agent_pin()entirely, leaving the existing pin alone(matching what the
OSErrorhandler right next to it already did for awrite that failed outright).
modules/src/lib/agents.sh:agent_upgrade()read the recorded pinand decided "already at this box's pin" before acquiring the per-harness
flock. Two concurrent upgrades for the same agent (the update service
loops over every configured user; a person can also run this by hand at
the same moment) could both pass that check before either took the lock.
If the second one's own
nix profile addthen failed, its recovery pathrestored what it still believed was the previous pin - silently undoing
the first process's already-successful upgrade. Moved the pin read to
right after the lock is acquired, matching how
agent_install()alreadyre-checks its own condition once it holds the lock ("The winner of the
race installed it while we waited; nothing to do.").
Both are narrow, no-design-trade-off fixes, so this goes straight to a PR
rather than an issue per this repo's
AGENTS.md.A third finding on the same PR -
SuccessExitStatus=0 1onagent-box-harness-upgrade@.servicemasking a genuine upgrade failure assuccess - is not included here: exit 1 is also what the unit returns for
the documented "commonest reason: a box is offline" case that
SuccessExitStatuswas added to tolerate, so narrowing it to0wouldregress that intent and start flagging offline boxes as failed. Distinguishing
"offline/transient" from "genuinely broken" needs its own exit code, which is
a real design decision - tracking that separately rather than rushing it here.
Changes
bin/agentbox:resolve_agent_pin()returnsNoneon failure instead ofthe mutable ref; the caller only calls
write_agent_pin()when it got areal pin back.
modules/src/lib/agents.sh: move the pin read and "already at pin" checkin
agent_upgrade()to after the flock is acquired.modules/agent-box.nix: regenerated (python3 bin/assemble-module.py).tests/golden/vm/payloads/{agent-box-harness,agent-box-supervisor}/...:regenerated (
nix run .#update-golden).Test plan
bash tests/test-jit-agents.sh modules/src/lib/agents.sh- allassertions pass, no regressions (including the existing "an upgrade at the
same pin runs no nix at all" and rollback-on-failed-add cases).
python3 -m py_compile bin/agentboxpython3 scripts/check_backend_parity.py- OK, every divergencedeclared.
nix build .#checks.aarch64-linux.{module-generated-up-to-date,golden-snapshot,one-spec-both-backends,multi-user,backend-parity,jit-agents,runtime-profile,module-single-file,phantom-unit-overrides}-all green (
runtime-profilealso confirmsbin/agentboxstill lints cleanunder
writePython3Bin's flake8 pass).🤖 Generated with Claude Code
https://claude.ai/code/session_01MB26GQRXxhfGYoxWTsUp6M