Repository navigation
fix(deploy): one agent-runtime install, the deployed one - #2236
Open
abretonc7s wants to merge 1 commit into
Open
abretonc7s wants to merge 1 commit into
abretonc7s wants to merge 1 commit into
Conversation
The engine tells a worker to run `farmslot-agent` — the escape hatch in a refusal message, the mark help, the farmslot-farm recipe fixture — but a deploy only ever linked `farmslot`. That bin kept resolving to whatever npm had installed globally, on mini an agent-runtime 0.4.0 that predates every worker-side fix in this revision, so a worker calling it directly bypassed the wrapper's refusals. A deploy now links `farmslot-agent` from the same snapshot as `farmslot`, by the same rules and in all three layouts, uninstalls any global `@farmslot/*` package first (npm's uninstall removes the bins it owns, so doing it after linking would delete ours), and then verifies: no global `@farmslot` package may remain, and both bins must resolve inside the install. The verification resolves its allowed prefixes as well as the link, since /var is a symlink to /private/var on macOS and comparing a resolved path against an unresolved prefix rejects a good link. It uses prefix tests rather than `case`, because bash 3.2 — what these nodes run — parses this heredoc body as code inside the surrounding command substitution, where a `;;` is a syntax error that stops the whole script from loading. An installed revision now means both bins point at the snapshot, so the redeploy fixture seeds both; `seedSnapshot` also writes the agent-runtime bin that a real snapshot always carries.
This branch has not been deployed
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.
Why
The engine tells a worker to run
farmslot-agent: the escape hatch in a refused mark, the mark help, thefarmslot-farmrecipe fixture. A deploy only ever linkedfarmslot, so that bin resolved to whatever npm had installed globally. On mini that was@farmslot/agent-runtime0.4.0, predating every worker-side fix in this revision, which is how a worker reached mark behaviour the current wrapper refuses.Audit before the change (mini, macwork; macpro excluded, ssh down):
~/.npm-global/lib/node_modules/@farmslot/agent-runtime0.4.0 on mini, first on PATH forfarmslot-agentfarmslot, the pack templates or the skills needs a PATH-global copy; every legitimate caller wants the deployed revisionWhat
farmslot-agentis linked from the same snapshot asfarmslot, by the same rules, in all three layouts (unmigrated, layout 2, legacy), with afarmslot-agent-shimmirroringfarmslot-shimfor instance resolution.@farmslot/*package is uninstalled first. npm's uninstall removes the bins it owns, so doing this after linking would delete ours. A failed uninstall stops the deploy with the package name rather than falling back torm -rf.@farmslotpackage may remain, and both bins must resolve inside the install.Notes for review
Two defects of mine during this change were both in the verification, not the linking, and both invisible to the check I had run:
case. bash 3.2, which these nodes run, parses this heredoc body as code inside the surrounding$( ), where;;is a syntax error that stopped the whole script from loading.bash -nhad passed because it ran under bash 5.3 and on the outer file only. Replaced with prefix tests;/bin/bash -nnow verified on the outer file and on both extracted heredoc bodies./varis a symlink to/private/varon macOS, so every good link was rejected. Prefixes are resolved too, and the unresolved comparison is kept so either form matches.Please attack the guard rather than the linking — that is where I have now been wrong twice.
Proof
scripts/deploy-node.test.mjs: 73/73, matching the pre-change baseline (fail 0).The redeploy idempotence test needed a fixture change, not an assertion change: an installed revision now means both bins point at the snapshot, so the fixture seeds both, and
seedSnapshotwrites the agent-runtime bin a real snapshot always carries. The "moves nothing on redeploy" assertion is unchanged.Live proof after merge: a deploy to mini and macwork showing both bins resolving into the snapshot and no global
@farmslotpackage. macpro once its ssh is restored.