[Daily #1330] mcp-server — the "Add MCP Server" button never renders for the server-everything Streamable-HTTP case (recurrent 2×)

[Victor-w-Madeira]

Spun out of daily-failure triage #1330 (run 31093877484, 2026-08-06).

Upstream: not filed

Symptom

The @stable test that registers a Streamable-HTTP MCP server hard-failed on all three attempts: add-mcp-server-button is reported element(s) not found after 15 s — the button is not late, it is absent from the DOM for the whole wait. @stable was auto-removed by the workflow (commit cb3082d).

Spec (line)	Waits for	Signature
tests/tests-automations/regression/mcp/server/mcp-server.spec.ts:1128 ("Streamable HTTP MCP server with server-everything should load tools correctly")	getByTestId('add-mcp-server-button') → visible (15 s)	Error: expect(locator).toBeVisible() failed

Why these failures are one cause

Single spec, single symptom — no grouping. It is filed on its own rather than with the other MCP row of this run (mcp-server-tab.spec.ts:6, tracked separately) because the two observations differ in kind: this one is deterministic and the element never exists, while that one is an intermittent 3 s click timeout on a different testid (mcp-server-dropdown) that passed on retry. A shared cause is plausible and worth checking from either side, but nothing in this run's artifacts establishes it.

Preliminary read (descriptive — NOT a verdict)

Descriptive observations only:

• The failure is deterministic across all 3 attempts (25.3 s / 25.5 s / 20.7 s) with identical wording, which is not the shape of a load or timing problem.
• The locator resolves to nothing at all (element(s) not found), not to a hidden or detached element — so the reachable states are: the button was renamed/removed upstream, or the flow never arrives at the screen that renders it.
• First seen 2026-08-05, repeated 2026-08-06 — the two most recent dailies, and none before in the 30-day window.
• Dedup: not [Daily #1258] mcp-server — GET /api/v2/mcp/servers times out when changing tool mode (recurrent 3×, load/reachability) #1266 (GET /api/v2/mcp/servers times out when changing tool mode) — different endpoint, different testid, different signature.

Investigation directive

All paths must be investigated independently, and the product is the prime suspect first: confirm on the current nightly whether add-mcp-server-button still exists in the Langflow frontend and whether the path this spec walks still reaches the screen that renders it. A "test wrong / selector drift" explanation may be accepted only after ruling out that the button (or the registration entry point) regressed. Then check the test path (navigation/wait strategy), then the environment. Recurrence started on 2026-08-05 — bisecting the nightly image between the 08-04 and 08-05 dailies is a cheap way to bound the change.

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.
• State explicitly whether mcp-server-tab.spec.ts:6 (tracked separately, this run's row 4) shares this cause — if it does, cross-link and consolidate.