Spun out of daily-failure triage #1121 (run 30534416609, 2026-07-30). @stable was auto-removed from this test by the daily workflow (committed to main). 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
On the Settings → MCP Servers page, the first server row renders the name langflow-agentic; the test asserts it contains lf-starter_project. The failure is deterministic — identical on all 3 attempts — and it is the very first assertion of the spec, so nothing after it (project creation, rename, delete) was exercised at all.
| Spec (line) |
Waits for |
Signature |
tests-automations/regression/mcp/server/mcp-server-starter-projects.spec.ts:7 ("user must be able to see starter projects for mcp servers") |
getByTestId("mcp_server_name_0") textContent to contain "lf-starter_project" |
Error: expect(received).toContain(expected) // indexOf |
Why these failures are one cause
Single test, single assertion — no grouping claim. Filed on its own because the symptom is a name mismatch on a settings row, unrelated to the day's other hard failure (a keyboard-focus path in ui-ux/).
Preliminary read (descriptive — NOT a verdict)
Two readings fit the evidence, and the triage asserts neither. (a) Row addressing: the assertion reads mcp_server_name_0 — index 0 of whatever the page lists first. The daily runs against a shared superuser account, and cleanOldFolders(page) runs immediately before, so if a project named langflow-agentic survives that sweep (or is created by a concurrent shard), it can legitimately occupy row 0 while the starter project sits further down. (b) Upstream rename: the starter project — and therefore the lf-<project> MCP server name derived from it — may have been renamed upstream, in which case langflow-agentic is the new expected value and the test is asserting a stale constant. Determinism across 3 attempts rules out a timing/wait defect either way.
Investigation directive
- Reproduce against the current
langflowai/langflow-nightly:latest at --retries=0 and capture the full MCP Servers list, not just row 0.
- Read
GET /api/v1/mcp/servers (or the endpoint the page consumes) directly: establish whether a starter-project-derived lf-starter_project entry exists at all, or whether the starter project itself was renamed upstream.
- If it exists but is not first, the defect is the index-0 addressing plus whatever leaves
langflow-agentic on the account — decide whether cleanOldFolders should remove it, or whether the assertion should address the row by name.
- If it does not exist, treat it as an upstream naming change, record the new expected value, and check which other specs assume
lf-starter_project.
Deliverables (Done when)
Spun out of daily-failure triage #1121 (run 30534416609, 2026-07-30).
@stablewas auto-removed from this test by the daily workflow (committed tomain). 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
On the Settings → MCP Servers page, the first server row renders the name
langflow-agentic; the test asserts it containslf-starter_project. The failure is deterministic — identical on all 3 attempts — and it is the very first assertion of the spec, so nothing after it (project creation, rename, delete) was exercised at all.tests-automations/regression/mcp/server/mcp-server-starter-projects.spec.ts:7("user must be able to see starter projects for mcp servers")getByTestId("mcp_server_name_0") textContent to contain "lf-starter_project"Error: expect(received).toContain(expected) // indexOfWhy these failures are one cause
Single test, single assertion — no grouping claim. Filed on its own because the symptom is a name mismatch on a settings row, unrelated to the day's other hard failure (a keyboard-focus path in
ui-ux/).Preliminary read (descriptive — NOT a verdict)
Two readings fit the evidence, and the triage asserts neither. (a) Row addressing: the assertion reads
mcp_server_name_0— index 0 of whatever the page lists first. The daily runs against a shared superuser account, andcleanOldFolders(page)runs immediately before, so if a project namedlangflow-agenticsurvives that sweep (or is created by a concurrent shard), it can legitimately occupy row 0 while the starter project sits further down. (b) Upstream rename: the starter project — and therefore thelf-<project>MCP server name derived from it — may have been renamed upstream, in which caselangflow-agenticis the new expected value and the test is asserting a stale constant. Determinism across 3 attempts rules out a timing/wait defect either way.Investigation directive
langflowai/langflow-nightly:latestat--retries=0and capture the full MCP Servers list, not just row 0.GET /api/v1/mcp/servers(or the endpoint the page consumes) directly: establish whether a starter-project-derivedlf-starter_projectentry exists at all, or whether the starter project itself was renamed upstream.langflow-agenticon the account — decide whethercleanOldFoldersshould remove it, or whether the assertion should address the row by name.lf-starter_project.Deliverables (Done when)
--retries=0runs), fixing waits/flow as needed.test.fixmeand restore@stable, re-validated perCONTRIBUTING.md. (Nothing to lift if nothing was quarantined.)langflowai/langflow-nightly:latest(or therelease-1.x.xbranch), is re-validated there, and@stableis restored — not on a test-side mute.@stablerestored on the test (it was auto-removed by the daily workflow), re-validated perCONTRIBUTING.md.