[Daily #1121] mcp-client-regression: page.waitForURL times out on the blank-flow entry point (recurrent flake, 3×)

[Victor-w-Madeira]

Spun out of daily-failure triage #1121 (run 30534416609, 2026-07-30). The run was a clean, non-guarded daily (466 passed, 2 hard failures, 10 flakes — the mass-failure guard did not trip), so this failure is not mass-failure collateral. Backend liveness measured no mid-run outage on 4/4 shards, but 31 single-probe failures were discarded as blips, so a wedge is not fully ruled out for the run (#1030); this test's last error is not transport-level, and the run attributed it to the spec.

Upstream: not filed

Symptom

openBlankFlow() creates the flow successfully and then never sees the navigation: page.waitForURL: Timeout 30000ms exceeded waiting for a URL matching /flow/ until load. Recovered on retry (1 failed attempt of 2). Same-signature recurrent across the dailies of 2026-07-16, 2026-07-20 and 2026-07-30 (the same test also failed on 07-10 and 07-14 under different signatures — context only, not part of the recurrence count).

Spec (line)	Waits for	Signature
tests-automations/regression/mcp/client/mcp-client-regression.spec.ts:238 ("unreachable HTTP server results in empty tool dropdown")	page.waitForURL(/\/flow\//) after the blank-flow click (30 s)	TimeoutError: page.waitForURL: Timeout 30000ms exceeded.

Why these failures are one cause

Single test, single signature — no grouping claim. Filed separately from #966, which is waitForURL-adjacent in wording only: its signature is an expect(received).toBe(expected) inside open-new-flow-templates-modal.ts on run-flow.spec.ts:12.

Preliminary read (descriptive — NOT a verdict)

The wait that times out is at mcp-client-regression.spec.ts openBlankFlow(), after the helper has already observed POST /api/v1/flows return 201 and read the new flow id — so the flow exists server-side and the failure is that the SPA never routes to /flow/<id>. The helper's own retry loop does not cover this: it re-clicks only on a 5xx, and a 201 followed by no navigation falls straight through to the throw. Whether the router is genuinely stuck or merely slower than 30 s under the daily's parallel load is exactly what the investigation has to separate — the broad load hypothesis is tracked on #773. No cause asserted here.

Investigation directive

1. Reproduce at --retries=0 against the current nightly, and under parallel load comparable to the daily, to establish a rate.
2. From the failing trace, confirm the 201 and then check the page: did the URL change at all, did an error toast render, did the editor mount without the URL updating?
3. Measure how long the navigation takes when it does succeed — if the p95 is close to 30 s the wait is under-budgeted rather than the app being stuck.
4. Decide whether openBlankFlow() should treat 201-without-navigation as a retryable state (it currently retries only on 5xx), and whether the other three tests in this file that call the same helper need the same treatment.

Deliverables (Done when)

• Root cause confirmed per spec (product regression vs. test/wait-strategy vs. environment), with evidence on the current nightly.
• Each spec passes reliably (multiple clean --retries=0 runs), fixing waits/flow as needed.
• Quarantine lifted in the fix PR — remove test.fixme and restore @stable, re-validated per CONTRIBUTING.md. (Nothing to lift if nothing was quarantined.)
• If the root cause is a product (Langflow) regression: recorded as such here, and this issue stays open until the upstream fix lands in langflowai/langflow-nightly:latest (or the release-1.x.x branch), is re-validated there, and @stable is restored — not on a test-side mute.

Flake signal

This test is confirmed recurrent (dailies 2026-07-16, 2026-07-20, 2026-07-30). As prevention it was quarantined at triage — @stable removed and test.fixme added — so it stops running in every context (daily, PR impacted-specs gate, full suite) until this issue is worked:

• tests/tests-automations/regression/mcp/client/mcp-client-regression.spec.ts (test at line 238)

Lifting the quarantine after the fix (remove test.fixme + restore @stable) is a deliverable of this issue.

[Victor-w-Madeira]

Quarantined at triage in PR #1127 — @stable removed and test.fixme added at tests/tests-automations/regression/mcp/client/mcp-client-regression.spec.ts:238. Lifting it is a deliverable of this issue.