From c6864996f06bed0de4090fb4e41f5cfa5dc726a7 Mon Sep 17 00:00:00 2001
From: Vuong Hoang <vh@phasefinal.com>
Date: Mon, 18 May 2026 23:47:51 -0700
Subject: [PATCH] skaldsong playbook: verify container is Up, not 'healthy'
 (was racing start_period)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The verify step ran 0.09s after `docker compose up -d --force-recreate`,
well before the container's 30s start_period elapsed — so 'healthy'
isn't yet in docker ps's Status string and the grep failed. False
negative; container was operationally up (verify 1/2 already confirmed
/health 200).

Greping for '^Up' instead catches the case verify 2/2 actually wants
to catch (container exited entirely) without racing the healthcheck.
---
 playbooks/deploy-skaldsong.yaml | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/playbooks/deploy-skaldsong.yaml b/playbooks/deploy-skaldsong.yaml
index 9094e82..c6bc254 100644
--- a/playbooks/deploy-skaldsong.yaml
+++ b/playbooks/deploy-skaldsong.yaml
@@ -112,6 +112,12 @@ verify:
     shell: curl -sf -o /dev/null http://localhost:{{ host_port }}/health
     changed_when: "false"
 
-  - name: skaldsong container running + healthy
-    shell: docker ps --filter name=^/skaldsong$ --format '{{.Status}}' | grep -q 'healthy'
+  - name: skaldsong container running
+    # Grep for '^Up' (not 'healthy') — verify runs immediately after the
+    # deploy step finishes, which is well before the container's
+    # start_period (30s) elapses. The 'healthy' state from docker ps is
+    # a delayed echo of the same /health probe verify 1/2 already
+    # confirms, so racing the start_period here is bogus. Keep this
+    # check to catch the "container exited entirely" case.
+    shell: docker ps --filter name=^/skaldsong$ --format '{{.Status}}' | grep -q '^Up'
     changed_when: "false"