test(deploy): widen the live-worker 200 poll for fresh workers.dev propagation

The env plumbing is fixed and the live deploy now runs in CI, but the first run
failed the 200 check: a brand-new *.workers.dev hostname (unique per run) needs
its route to propagate globally before the first request succeeds, and that
window is longer from a CI runner than a dev machine (a solid 30s of 404s). Poll
up to ~2 min, and on a persistent non-200 report the URL plus whether the
workers.dev route is enabled — to tell slow propagation from a route that never
went live. Remove the temporary env-location probes.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019wnwcxjavdb2xys8XGZora

Author: Brooooooklyn

.github/workflows/ci.yml

@@ -54,10 +54,6 @@ jobs:
       - run: vp exec playwright install chromium
         if: ${{ contains(matrix.os, 'windows') }}
 
-      # TEMP diagnostic (remove after): confirm the step shell has all three vars before `vp run`.
-      - name: e2e env in step shell (debug)
-        run: node -e "console.log('[[STEP]] token', (process.env.VOID_E2E_CF_TOKEN||'').length, 'account', (process.env.VOID_E2E_CF_ACCOUNT_ID||'').length, 'runid', (process.env.VOID_E2E_RUN_ID||'').length)"
-
       - run: vp run test:all
 
   done:

packages/void/test/e2e/cloudflare-deploy-live.test.ts

@@ -248,13 +248,15 @@ function extractWorkerUrl(output: string): string | undefined {
 }
 
 /**
- * Poll the live worker until it serves a 200 (edge propagation can lag the deploy by a few seconds,
- * and a freshly-deployed route can transiently 404 or 5xx before it is live). Retries on ANY
+ * Poll the live worker until it serves a 200. A BRAND-NEW `*.workers.dev` hostname (every run uses a
+ * unique worker name) needs the route to propagate globally before the first request succeeds, and
+ * that window is materially longer from a CI runner's network path than from a dev machine — a run
+ * observed a solid 30s of 404s before the route went live. So poll generously (~2 min). Retries on ANY
  * non-200 — not just 5xx — so a propagation-window 404 is not mistaken for the final answer. On
- * exhaustion returns the LAST response so the caller's status assertion reports the real final
- * status; throws only when every attempt was a network error (no response at all).
+ * exhaustion returns the LAST response so the caller's status assertion reports the real final status;
+ * throws only when every attempt was a network error (no response at all).
  */
-async function fetchWithRetry(url: string, attempts = 10): Promise<Response> {
+async function fetchWithRetry(url: string, attempts = 40, delayMs = 3000): Promise<Response> {
   let lastResponse: Response | undefined;
   let lastError: unknown;
   for (let i = 0; i < attempts; i++) {
@@ -269,14 +271,34 @@ async function fetchWithRetry(url: string, attempts = 10): Promise<Response> {
       lastError = error;
       lastResponse = undefined;
     }
-    await new Promise((resolve) => setTimeout(resolve, 3000));
+    if (i < attempts - 1) {
+      await new Promise((resolve) => setTimeout(resolve, delayMs));
+    }
   }
   if (lastResponse) {
     return lastResponse;
   }
   throw lastError ?? new Error(`worker at ${url} never answered`);
 }
 
+/**
+ * Whether the deployed worker has its `*.workers.dev` route enabled, for diagnosing a persistent 404.
+ * A propagation-window 404 has the route enabled (just not live yet); a route that is DISABLED 404s
+ * forever. Best-effort — returns a short human string, never throws.
+ */
+async function workersDevEnabled(): Promise<string> {
+  try {
+    const res = await fetch(
+      `https://api.cloudflare.com/client/v4/accounts/${cfAccountId()}/workers/scripts/${WORKER_NAME}/subdomain`,
+      { headers: { Authorization: `Bearer ${cfToken()}` } },
+    );
+    const body = (await res.json().catch(() => ({}))) as { result?: unknown };
+    return `workers.dev subdomain endpoint ${res.status}: ${JSON.stringify(body.result ?? body)}`;
+  } catch (error) {
+    return `workers.dev subdomain check errored: ${String(error)}`;
+  }
+}
+
 describe('void deploy --backend cloudflare (live account)', () => {
   beforeAll(async () => {
     // Gate at execution time (see the credential note): when the token/account are absent the suite is
@@ -482,7 +504,12 @@ describe('void deploy --backend cloudflare (live account)', () => {
     ctx.skip(!e2eEnabled(), NO_CREDS_NOTE);
     const base = extractWorkerUrl(deployOutput);
     expect(base, deployOutput).toBeDefined();
-    const res = await fetchWithRetry(`${base!.replace(/\/$/, '')}/api/hello`);
-    expect(res.status).toBe(200);
-  });
+    const url = `${base!.replace(/\/$/, '')}/api/hello`;
+    const res = await fetchWithRetry(url);
+    // On a persistent non-200, report the URL + whether the workers.dev route is even enabled, to
+    // tell a slow-propagation 404 (route enabled) from a route that never went live (disabled).
+    const diagnostic =
+      res.status === 200 ? '' : ` — GET ${url} → ${res.status}; ${await workersDevEnabled()}`;
+    expect(res.status, `worker ${WORKER_NAME}${diagnostic}`).toBe(200);
+  }, 200_000);
 });

vite.config.ts

@@ -13,12 +13,6 @@ const e2eWorkerEnv = {
   VOID_E2E_CF_ACCOUNT_ID: process.env.VOID_E2E_CF_ACCOUNT_ID ?? '',
   VOID_E2E_RUN_ID: process.env.VOID_E2E_RUN_ID ?? '',
 };
-// TEMP diagnostic (remove after): does the vitest MAIN config process have the vars? If account is 0
-// here while the CI step shell had 32, the env is filtered before vitest (in `vp run`), so test.env
-// cannot recover it.
-console.error(
-  `[[CFG]] token=${(process.env.VOID_E2E_CF_TOKEN ?? '').length} account=${(process.env.VOID_E2E_CF_ACCOUNT_ID ?? '').length} runid=${(process.env.VOID_E2E_RUN_ID ?? '').length}`,
-);
 
 // Windows CI runners are 2-3x slower for builds and server startup.
 const ciTimeoutScale = process.platform === 'win32' ? 3 : 1;