Repository navigation
feat(sync): post-sync actions need a durable record and a node-level plan in the orchestrator #17455
Description
Parent: #17452
Depends on: #17453
Problem
The owner asks that post-sync actions be part of the code-sync process and its logs, rather than a
separate button bar.
An automated path already exists, and that reframes this issue — it is not "build automation",
it is "the automation has no record and no node-level plan". sync_orchestrator.py runs
_run_post_sync_cmd then _restart_systemd_service per role (lines 216-245), in the right order
within a role. What it does not do:
- leave a durable record. A failure goes to the application logger
(logger.error("Post-sync command exited %s: %s", ...)) with an 800-character output tail. There
is no per-action row anyone can read after the fact, so the sync's own history cannot answer
"what post-sync work ran, and did it succeed". - order or deduplicate across roles. Each role syncs independently, so a unit owned by two
roles (SLM role shape has two sources of truth: role_registry.DEFAULT_ROLES vs autobot-infrastructure/*/manifest.yml #16025) restarts twice here too, and a shared-library install can land after a dependent
service has already restarted.
So the manual bar is a parallel surface that re-derives the same work, and #17453 is fixing the
ordering on the surface that is not the automated one. That asymmetry is the thing to remove.
Shape
Reuse #17453's ordered_post_sync_plan rather than growing a second ordering policy in the
orchestrator — two node-level plans would be the original defect one level up.
Acceptance criteria
- Each post-sync action executed by a sync leaves a durable record: what ran, when, exit status,
output tail. - The record is reachable from wherever the sync run is shown, so the manual bar is a fallback
rather than the only view of this work. - The orchestrator orders and deduplicates across roles using the same policy as the endpoint —
one implementation, imported, not reimplemented. - A unit owned by two roles restarts once per sync, asserted by a test.
- A post-sync failure is visible in the run's record and not only in the application log.
Activity
fix(orchestration): order post-sync actions and restart each unit once (
mrveiss commentedon Oct 10, 2026
Decisions needed (owner): deploy-visible, recorded by the de-fork master session while the owner is away. Surveyed by autobot-ai-ad. Recommendations in brackets:
_CATEGORY_RANK)? [Node-major, but the self-killing unit (slm-backend,_COMPONENT_SERVICESdiscovery(deploy): autobot_shared/library restart path has no post-restart health poll or rollback #11496) stays LAST and chromadb restarts before ai-stack. The rule lives once in_post_sync_plan.]sudo -n, failing fast without NOPASSWD sudo instead of waiting out 60 s, with failures recorded rather than swallowed. [Yes, matching the other two restart paths.]post_sync_action_runstable plus a migration: a schema addition, not a rewrite. [Yes.]Meanwhile: #18186 (three SSH-restart implementations) is being consolidated with ZERO behaviour change. Each site keeps its current flags and timeouts as explicit parameters, so the
-n/timeout unification above becomes a one-line follow-up once decided. Thecode_sync.pywiring and #17489 wait for the queued redaction branch, which owns that file.code_sync's component step order is unchanged (the recorded #17867 decision).mrveiss commentedon Oct 10, 2026
Owner decision (2026-10-10): all four yes.
_post_sync_plan.sudo -nand records failures.post_sync_action_runstable plus migration.