Repository navigation
deploy: dependency rollback is reachable only by hand — no service, task or update path invokes its playbooks #17257
Description
Activity
- added a commit that references this issue
on Sep 22, 2026 - changed the title
[-]not-wired(ansible): the dependency_patching rollback role is fully implemented and invoked by nothing[/-][+]deploy: dependency rollback is reachable only by hand — no service, task or update path invokes its playbooks[/+]on Sep 22, 2026 Closing: not a defect. The premise was wrong three times, and I filed it on the first one.
dependency_patchingis fully wired. Verified references, all read directly:Reference playbooks/patch-dependencies.ymlfive - role: dependency_patchinginvocations, lines 63/75/87/99/111playbooks/rollback-dependencies.yml,patch-system-packages.yml,rollback-system-packages.ymlrole invocations ansible/deploy.shruns both dependency playbooks — patch_dependencies()at :359,run_playbook "patch-dependencies.yml"at :372,"rollback-dependencies.yml"at :388, CLI flags at :491-493, dispatch at :646-649autobot-backend/api/settings.py:213run_system_update_endpoint, an admin route that triggerspatch-dependencies.ymlas a Celery taskSo there is a role, a playbook layer, an operator CLI and an admin API route. Nothing is orphaned.
How this issue came to exist
Three claims, three wrong, each from a grep whose scope could not contain the answer:
- "Invoked by nothing" — greps covering
api/*.py,services/*.pyand two named playbooks. The four playbooks that invoke the role were outside that scope. I filed this issue from that, without verifying the negative. - "Reachable only by hand" — after review corrected (1). This used
grep -rn "patch-dependencies|patch_dependencies", andgreptreats|literally without-E, so it matched nothing for a reason unrelated to the question. An empty result from a broken instrument, read as an absence. - "four times" — a grep piped through
head -4. It is five.
The one thing that is true:
update-all-nodes.ymldoes not include the role. Given a dedicated patch/rollback CLI and an admin API route, that reads as deliberate separation rather than a gap, and I am not going to file a fourth version of this claim to assert otherwise.What is worth keeping
Not this issue — the method.
docs/developer/MEASUREMENT_DISCIPLINE.mdalready names the failure: an instrument answers a narrower question than the one it is read as answering, and the narrow answer is empty. Three consecutive instances on one claim, each surviving because the output was empty and empty looked like absence. Verifying a negative means enumerating where the thing could be referenced, not grepping where you expect it — and checking the instrument works before trusting its silence.Recorded against #17259, which is that rule as a product property.
- "Invoked by nothing" — greps covering
- added 7 commits that reference this issue
on Sep 22, 2026
What is actually true
autobot-slm-backend/ansible/roles/dependency_patching/is wired — to playbooks:playbooks/patch-dependencies.yml- role: dependency_patchinginvocations (phases 1-5, lines 63/75/87/99/111)playbooks/rollback-dependencies.ymlplaybooks/patch-system-packages.ymlplaybooks/rollback-system-packages.ymlSo the role is not orphaned, and it is not dead code.
The finding that survives
Nothing runs those playbooks. Repo-wide, outside tests:
No service, no API route, and no scheduled task invokes
patch-dependencies.ymlorrollback-dependencies.yml, and the main update path —update-all-nodes.yml— does not includethe role. The capability is reachable only by an operator running a playbook by hand.
That still matters for a rollback mechanism specifically: it is the thing you need at the
moment an update has gone wrong, which is the moment nobody is going to be reading
playbooks/to discover that a manual entry point exists. But "reachable only by hand" is a different and
smaller claim than "invoked by nothing", and the fix is correspondingly smaller.
Acceptance criteria
whether the update path should invoke it — either is defensible; the gap is that neither
was chosen.
update will actually find it, not only in
playbooks/.update-all-nodes.ymlinvokes it and the backup is shown to beproduced and restored on a real host.
least once against a real target.
Method note, because this issue is its own example
The original claim was produced by a grep over a scope that could not see the answer, and the
empty result was read as an absence.
docs/developer/MEASUREMENT_DISCIPLINE.mdnames exactlythis: an instrument answers a narrower question than the one it is read as answering, and the
narrow answer is empty. Verifying a negative means enumerating where the thing could be
referenced, not grepping where you expect it.
Related