Files
kevinveenbirkenbachandClaude Opus 5 7f1025e4a7 fix(qdrant): render the stack before flushing its rebuild
svc-ai-mcp-adapter/tasks/rebuild.yml notifies compose-build and compose-up.
00_core.yml then flushed two tasks later, while the stack it was about to act
on had not been rendered yet: qdrant reaches sys-svc-compose only at the end,
through utils/network/routine.yml, not at the start through sys-stk-full.

svc-ai-mcp-adapter/tasks/instance.yml:12-16 already names this hazard in prose
and works around it with five explicit `notify: []` entries, because a
notification raised before the render "fires a compose up against a project
that has no compose.yml yet"; it records that rebuild.yml raises it once both
the context and the compose file exist. The flush in between broke that.

Drop it. The notification now survives to the flush inside
utils/network/routine.yml:13-17, which enters sys-svc-compose with
compose_handlers_flush: true, i.e. after 02_stack_host_prep has rendered and
under qdrant's own application_id.

That alone would move the notification into the window where routine.yml:2-6
pulls in sys-svc-container, whose 00_core.yml:53 is an unconditional
meta: flush_handlers, so a play in which qdrant is the first compose consumer
would drain it before the wrapper exists. The guarded bootstrap ahead of the
notify absorbs that flush against an empty queue, the same shape 252b3e58b2
applies in sys-svc-rdbms.

Only qdrant is affected. The commit that added the sidecars gave ten roles
this shape; the three others that pair rebuild with a flush render first and
are correct: web-svc-libretranslate (sys-stk-full :9, rebuild :13, flush :17),
web-app-prometheus (sys-stk-backend :11, rebuild :56, flush :60) and
web-app-zammad (sys-stk-full :11, rebuild :16, flush :24). qdrant is the only
svc-db role in that set, and svc-db roles load their stack last.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-04 02:39:11 +02:00
..
…