mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 19:01:54 +00:00
kevinveenbirkenbachandClaude Opus 5.5
2ceba492b8
In swarm, docker stack deploy ignores depends_on, so the precheck service and every init replica ran search_allocation_precheck.sh at the same time. They shared one probe index: one invocation's PUT could fail the shards_acknowledged check because another had created the index first, and either one's cleanup could delete the other's probe. The init service carries no replica override, so compose_replicas gives it one task per host in the application group and the collision also happens between init replicas. A failing precheck task also never reached has_fatal_task in stack_ready.sh: with restart_policy none it records a single error, while has_fatal_task needs three. stack_ready.sh then kept answering "not converged" until the handler ran out of retries. And a Running init task counts as converged through running_current_spec, so the swarm deploy never depended on init failing; the role's "wait for Zammad init" task is what stops it. The probe index now carries the container's hostname, which docker sets to the container id, so concurrent invocations no longer share an index. compose.yml.j2 renders the precheck service, and init's service_completed_successfully dependency on it, only outside swarm. Compose keeps its fast stop on a refusal; in swarm, init runs the same check in front of zammad-init, a refusal leaves Zammad unseeded, the wait for Zammad init fails the deploy, and the init service logs carry the allocation explanation. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>