mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 02:54:26 +00:00
kevinveenbirkenbachandClaude Opus 5
252b3e58b2
Two branch-only commits each armed a defect in the compose-up handler topic, and both failed in run 33785198875.63f7f962bfregistered the topic owner at the top of sys-svc-rdbms' dedicated.yml so the notify two tasks below stopped aborting with ERROR_ON_MISSING_HANDLER. The notification then survived to the unconditional meta: flush_handlers at sys-svc-container/tasks/00_core.yml:53, reached from sys-svc-compose's own 00_core before that role installs BIN_COMPOSE, and long before 02_stack_host_prep installs BIN_CA_INJECT. Matrix#1 died there on ca-inject with rc 2 after seven retries. That play carries exactly one compose notification (job 100756596907, log line 11046), so closing this window is sufficient, not merely necessary. dedicated.yml now enters 00_core.yml under the role's run-once flag before it notifies, so the flush drains an empty queue and the flag then makes main.yml skip the body on the real entry. The registration itself stays ungated: gating it would skip the owner from the second app on.95186163aahoisted the sys-svc-compose include to sys-stk-backend position 1. The consumer therefore rendered and notified compose-up before sys-svc-objstore lazily loaded the provider app role, whose own unconditional flush consumed the notification and ran the single registered handler in the provider's chdir. mastodon and peertube never got a stack, in compose and in swarm alike; the victim's own guard task appears zero times in all four logs. Restoring the include below rdbms, objstore and engine puts the notify after every foreign crossing. Two pre-hoist runs in exactly that order are green on record. The test keeps its cases and gains one. It selects the render include by the absence of tasks_from instead of by first occurrence, so an early registration-only include stays legal while a hoisted render still fails. The new case pins the bootstrap: entry point, position before the first notify, and the run-once guard whose removal would let 01_reset.yml tear down DIR_COMPOSITIONS once per dedicated-DB app. Same class, pre-existing, not fixed here: svc-db-qdrant notifies and flushes three tasks before its first compose entry; web-app-magento pairs a dedicated database with a shared object store; web-app-seaweedfs still flushes a topic it does not own; svc-runner enters 00_core.yml unguarded. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>