fix(ci): require N consecutive HTTP successes in wait-for-grpc.sh (#63)

Observed flake: probe returns HTTP 200 once on the first attempt that
clears the connection-refused phase, exits, tests start, ALL tests fail
with 'TypeError: Failed to fetch' to the gRPC backend. The single-probe
gate isn't strict enough — a one-shot 200 (e.g. tonic-health responding
before the rest of the dispatcher is fully wired) currently passes.

Upgrade the readiness signal to N consecutive HTTP successes spaced
PROBE_INTERVAL apart (defaults: 3 successes, 0.5s apart), so the probe
only declares the server ready after ~1s of demonstrably-stable
response. Any non-success in the streak resets it to zero and the
slow-poll loop resumes — so a momentary blip during init doesn't get
counted twice on either side.

Tracked occurrences across recent PR runs: web-sdk PR #23 ci-shard-4,
PR #29 ci-shard-1 + ci-shard-4, PR #27 multiple shards.

Author: WiktorStarczewski

scripts/wait-for-grpc.sh

@@ -34,12 +34,27 @@ set -uo pipefail
 # and false-positived on a curl edge case that emitted "000000" (likely
 # an internal connection retry concatenating two failure codes). The
 # regex form is the strict version.
+#
+# Stability requirement: a single HTTP success isn't enough. Observed
+# flake mode: probe gets HTTP 200 once, exits, tests start, ALL tests
+# fail with `TypeError: Failed to fetch`. The HTTP layer can flicker up
+# briefly during init (e.g. a tonic-health endpoint comes online before
+# the rest of the dispatcher is fully wired). We require N consecutive
+# successes spaced ~PROBE_INTERVAL apart so a one-shot 200 doesn't pass
+# the gate. If the server flickers down between successes, the streak
+# resets to zero and the slow-poll loop resumes.
 
 BINARY="${1:?usage: $0 <binary> <port> [log-file] [timeout-seconds]}"
 PORT="${2:?usage: $0 <binary> <port> [log-file] [timeout-seconds]}"
 LOG_FILE="${3:-/tmp/$(basename "$BINARY").log}"
 TIMEOUT="${4:-90}"
 
+# Tunables. Conservative defaults — three consecutive successes 500ms
+# apart equals ~1s of stable response, which empirically clears the
+# observed flicker window.
+REQUIRED_STREAK=3
+PROBE_INTERVAL=0.5
+
 chmod +x "$BINARY"
 rm -f "$LOG_FILE"
 
@@ -48,6 +63,7 @@ BIN_PID=$!
 
 deadline=$((SECONDS + TIMEOUT))
 attempt=0
+streak=0
 while true; do
   attempt=$((attempt + 1))
 
@@ -57,10 +73,20 @@ while true; do
   # Any 1xx/2xx/3xx/4xx/5xx HTTP code = the server's HTTP layer is up.
   # Connection failures and timeouts produce "000" (or empty); we retry.
   if [[ "$http_code" =~ ^[1-5][0-9][0-9]$ ]]; then
-    echo "$(basename "$BINARY") gRPC dispatch responsive after ${attempt} attempt(s) (HTTP $http_code on port $PORT)"
-    break
+    streak=$((streak + 1))
+    if [ "$streak" -ge "$REQUIRED_STREAK" ]; then
+      echo "$(basename "$BINARY") gRPC dispatch stable after ${attempt} probe(s), ${REQUIRED_STREAK} consecutive HTTP successes (last code $http_code on port $PORT)"
+      break
+    fi
+    # Quick re-probe to confirm the streak.
+    sleep "$PROBE_INTERVAL"
+    continue
   fi
 
+  # Non-success → reset streak. A single bad probe in the middle of a
+  # would-be confirmation invalidates it — we want N IN A ROW.
+  streak=0
+
   if [ "$SECONDS" -ge "$deadline" ]; then
     echo "::error::$(basename "$BINARY") did not respond on port $PORT within ${TIMEOUT}s (last http_code='$http_code')"
     echo "--- $LOG_FILE tail ---"