Fix flaky fetch-jwt-svids integration test by waiting for the restarted server

Signed-off-by: Agustín Martínez Fayó <amartinezfayo@gmail.com>

Author: amartinezfayo

test/integration/common

@@ -144,6 +144,37 @@ check-server-started() {
   fail-now "timed out waiting for server to start"
 }
 
+# Counts how many times the server has logged that it started its APIs. The
+# server emits the "Starting Server APIs" line twice per boot (TCP and UDS
+# listeners).
+count-server-api-starts() {
+  # grep -c exits non-zero when there are no matches, which would trip the
+  # step's errexit/pipefail, so swallow that into a zero count.
+  docker compose logs "$1" | grep -c "Starting Server APIs" || true
+}
+
+# Like check-server-started but safe to use after "docker compose restart".
+# A restart reuses the same container, so its log still contains the
+# "Starting Server APIs" markers from the pre-restart boot. Callers capture the
+# marker count before restarting and pass it here so we wait for the restarted
+# server to emit its own two markers rather than returning on the stale ones.
+wait-for-server-restarted() {
+  local container="$1"
+  local baseline="$2"
+  local want=$((baseline + 2))
+  MAXCHECKS=30
+  CHECKINTERVAL=1
+  for ((i=1;i<=MAXCHECKS;i++)); do
+      log-info "checking for restarted server APIs ($i of $MAXCHECKS max)..."
+      if [ "$(count-server-api-starts "$container")" -ge "$want" ]; then
+          return 0
+      fi
+      sleep "${CHECKINTERVAL}"
+  done
+
+  fail-now "timed out waiting for server to restart"
+}
+
 check-log-line() {
   # Check at most 30 times (with one second in between) that the agent has
   # successfully synced down the workload entry.

test/integration/suites/fetch-jwt-svids/08-test-disabled-jwt

@@ -4,23 +4,40 @@ log-info "testing disabled JWT functionality..."
 
 # Replace with disable_jwt_svids = true configuration
 sed -i.bak "s#disable_jwt_svids = false#disable_jwt_svids = true#g" conf/server/server.conf
+
+# The restart reuses the container, so its log keeps the "Starting Server APIs"
+# markers from the original boot. Capture that count first and wait for the
+# restarted server to emit its own markers, otherwise the readiness check would
+# return on the stale ones before the server is actually listening again.
+baseline=$(count-server-api-starts spire-server)
 docker compose restart spire-server
-check-server-started spire-server
+wait-for-server-restarted spire-server "$baseline"
 
 test-jwt-disabled-command() {
     local test_name="$1"
     shift 1
     local command=("$@")
-    
-    if ! ERROR_OUTPUT=$("${command[@]}" 2>&1); then
+
+    # Retry to ride out the brief window right after the restart where the
+    # server (or the agent's connection to it) is not ready yet and the command
+    # fails with a transient transport error instead of the expected JWT
+    # disabled error. The agent JWT fetch reaches the server over its TCP API,
+    # so it is the check most prone to racing the restart.
+    local MAXCHECKS=15
+    local CHECKINTERVAL=1
+    for ((i=1;i<=MAXCHECKS;i++)); do
+        if ERROR_OUTPUT=$("${command[@]}" 2>&1); then
+            fail-now "$test_name should have failed when JWT is disabled"
+        fi
         if echo "$ERROR_OUTPUT" | grep -q "JWT functionality is disabled"; then
             log-info "✓ $test_name correctly failed with JWT disabled error"
-        else
-            fail-now "$test_name expected JWT disabled error, but got: $ERROR_OUTPUT"
+            return 0
         fi
-    else
-        fail-now "$test_name should have failed when JWT is disabled"
-    fi
+        log-info "$test_name not ready yet (attempt $i of $MAXCHECKS): $ERROR_OUTPUT"
+        sleep "${CHECKINTERVAL}"
+    done
+
+    fail-now "$test_name expected JWT disabled error, but got: $ERROR_OUTPUT"
 }
 
 test-jwt-disabled-command "JWT authority prepare" \