fix(mcp): repair the swallowed sidebar add behind the MCP-server flake (#1335)

[rafaelgiln]

Closes #1335.

Verdict: test-side, but not the one the issue proposed

#1335 read the failure as a wait-strategy problem — mcp-server-dropdown not clickable within the shared helper's 3 s budget — and its investigation directive proposed raising that budget to 15–30 s. The budget was never the cause, and raising it would have fixed nothing.

The failing attempt's own error-context.md shows an empty application "Flow canvas" with "Minimize all" disabled: there was no MCP component on the canvas at all. Both of the add-server widget's entry points hang off that node, so with no node there is nothing to wait for and no budget can help. The sidebar add had been swallowed — the #1304 class.

Measured on nightly 1.12.0.dev17 with an instrumented probe:

Observation	Measurement
First clicks on the MCP tab producing no node within 12 s	4 of 8
Of those, repaired by an identical second click	4 of 4
A landed add's node render time	91–108 ms
Its entry point visible after the node lands	6–15 ms, enabled, 8 of 8

The same class as #1304's 4/20 on the Components tab, and worse here. The product is not exonerated by this PR — the swallowed click is a real Langflow defect (#1304) and this only makes the suite survive it and name it.

What changed

1. addComponentFromSidebarWithoutSearch — the repair helper could only serve tabs that have a search box, because it unconditionally fills sidebar-search-input. The MCP tab has none, so every MCP spec clicked bare and inherited no repair. Split into its own export rather than an optional third argument: 34 call sites across 27 files pass the term positionally, and the two tabs differ in the post-failure evidence there is to report, not merely in whether one line runs. searchTerm/searchValue become nullable so the message can distinguish <none on this tab> from "" (a real observation on the Components tab — the input was reset). addComponentFromSidebar is behaviourally unchanged; it delegates to the same addWithRepair with a non-null term.

2. openAddMcpServerModal — decided its branch from a snap read. isVisible({ timeout: 1000 }) looks like a 1 s wait, but Playwright ignores that option, so the probe returned in ~1 ms and committed to the dropdown branch whenever the widget had not painted — then spent its whole 3 s budget on a locator that, in the no-servers case, never appears at all. It now waits for either entry point (.or(), no .first() — the branches are mutually exclusive, so a build rendering both fails loudly as a strict-mode violation) and branches on the settled state. The disabled "Loading servers…" state is asserted separately, so an unclearing load says "still disabled" instead of producing a bare click timeout.

3. The failure now names the cause. The old 3 s click() produced a call log of exactly one line — waiting for getByTestId('mcp-server-dropdown') — which reads as "the dropdown is late" and is what sent the issue after the budget. The new failure reports the canvas node count first and splits on it: 0 nodes points at the swallowed add and says a wait cannot fix it; a populated canvas points at a Langflow change to the component's server field. Covered by unit tests on both branches.

4. Cleanup that never existed. The spec doc claimed "no flows are left behind by design". False: the test creates two flows per run and registered a fresh test_server_<random> every time, deleting neither — 14 orphan test_server_* registrations had accumulated locally. Not merely litter: their count decides which branch the widget under test renders, so leaving them behind quietly stopped the spec from ever taking the empty-list path again. It also feeds #1266 — GET /api/v2/mcp/servers?action_count=true takes 7.3 s for two servers on this instance. Cleanup is id-scoped, never a wipe (#553); flow ids come from POST /api/v1/flows 201 bodies, not the canvas URL, which holds the stale bootstrap id (#681).

5. Quarantine lifted — test.fixme → test, @stable restored, per 938c547's stated deliverable.

Validation

Nightly 1.12.0.dev18, all --workers=1 --retries=0:

mcp-server-tab.spec.ts  --repeat-each=10  10 passed (6.6m)
mcp-server.spec.ts      full file          5 passed, 1 skipped, 1 failed
npm run test:units                       493 passed
typecheck / eslint                       clean (0 errors)
QA-CHECKLIST guard + coverage guard      pass

Orphans after 10 consecutive runs: 0 test_server_* and 0 New Flow* (measured against the API).

The click fix alone was not enough, and the second sample is why

Fixing the MCP-tab click measured 5/5 here. An independent --repeat-each=5 on the same branch came back 4/5 — and the one failure was not the #1335 signature. It landed 30 s later on waitForSelector: generic-node-title-arrangement: the API Request drag at the top of the test had been swallowed. Same product defect (#1304), a surface the click repair does not reach, and the same mis-attribution #1335 was filed under — a wait blamed for a gesture that never registered.

Configuration	Result
bare drag + repaired click	4 / 5 (the failure is the drag)
repaired drag + repaired click	10 / 10

dragComponentFromSidebar re-issues the drag once. The gesture is re-issued, not swapped for a click: dragging out of the sidebar is an interaction Langflow ships, and a spec that quietly stops exercising it stops covering it. The comment it replaces — "use dragTo which is more reliable than click on add-component-button" — predates the #1304 repair; neither gesture is reliable bare, both are reliable repaired.

swallowedAddMessage gained a gesture field rather than a second function. It defaults to "click", so the 34 existing call sites are byte-identical — pinned by a unit assertion, since a drifting default would have all of them reporting a drag they never performed. What does differ is branched: the trigger names dragTo() … onto the canvas; the evidence quotes 1/5 on dev18 rather than #1304's 4/20, which was measured on the click surface; and there is no "+" button, so it reads "sidebar entry still visible".

Force-fail — the add was removed on purpose so the canvas stayed empty; the failure is the attributed message naming the node count and pointing at the repair helper, not a mcp-server-dropdown timeout. (See the run output quoted in the PR discussion.)

The one failure is not this change's

Streamable HTTP MCP server with server-everything — not @stable (auto-removed in cb3082d), already filed as #1332, and its body is byte-identical here and on origin/main: this PR's only edits to that file are one import and three call swaps, none inside that test.

It fails on both sides, but not at the same point, measured back-to-back against the same backend, --grep server-everything, three attempts per side:

Ref	Result	Point of failure
origin/main	3/3 fail	add-mcp-server-button visibility — element(s) not found after 15 s (#1332's exact signature)
this branch	3/3 fail	later, at the toolsCount poll — null after 60 s (the ?action_count=true slowness behind #1266)

Both signatures map to already-open issues. What is not established is why the point splits so cleanly by side when the test body does not differ; the likeliest reason is that its line 1207 carries the same ignored-isVisible({ timeout }) race this PR fixes elsewhere, making the outcome state-dependent. Recorded as an observation for #1332 rather than a claim.

Reach of the shared helpers (#1335's last deliverable)

• helpers/mcp/open-add-mcp-server-modal.ts → exactly 2 specs: mcp-server-tab.spec.ts, mcp-server.spec.ts. Both validated above.
• helpers/flows/add-component-from-sidebar.ts → 34 call sites across 27 files, none of which move: the change is additive and addComponentFromSidebar's behaviour is identical for a non-null term (pinned by the unit lane).

🤖 Generated with Claude Code

[rafaelgiln]

Force-fail output

The add was removed from the spec on purpose so the canvas stayed empty. On nightly 1.12.0.dev18, --workers=1 --retries=0:

Error: [openAddMcpServerModal] neither "add-mcp-server-simple-button" (no servers
registered yet) nor "mcp-server-dropdown" (one or more registered) became visible
within 15000ms. There is NO node on the canvas, so the MCP component was never added
and neither entry point could ever render — the sidebar add was swallowed
(#1304/#1335 class, not a slow surface: no wait fixes it). Add the component through
a helper that repairs a dropped click (helpers/flows/add-component-from-sidebar.ts).

  at openAddMcpServerModal (tests/helpers/mcp/open-add-mcp-server-modal.ts:81:11)

Compare with what the same state produced before this PR — the entire call log:

waiting for getByTestId('mcp-server-dropdown')

That one line is why #1335 was filed as a 3 s budget too short and proposed raising it to 15–30 s. The budget was never the cause.

Environment after validation

Measured against the API after 8 runs across this branch and origin/main:

	count
MCP servers registered	2 (both pre-existing: langflow-agentic, lf-starter_project)
Orphan test_* servers	0
Orphan New Flow* flows	0

Note for #1332

GET /api/v2/mcp/servers?action_count=true answers in 7.3 s with only two servers on this instance. That is the endpoint behind #1266, and it is the reason the server-everything test's 60 s toolsCount poll does not close once a third server is added. It also means the orphan accumulation this PR fixes was feeding that latency — worth accounting for when #1332 and #1266 are picked up.

[rafaelgiln]

Update: a second sample found a second surface

The click fix measured 5/5 here. An independent --repeat-each=5 on the same branch came back 4/5, and the failure was not #1335's signature — it was the API Request drag at the top of the test being swallowed, surfacing 30 s later as waitForSelector: generic-node-title-arrangement:

TimeoutError: page.waitForSelector: Timeout 30000ms exceeded.
Call log:
  - waiting for locator('[data-testid="generic-node-title-arrangement"]') to be visible

> 113 |     await page.waitForSelector(
      |                ^

Line 113 is the wait; the gesture that failed is line 109-111, the dragTo. Exactly the shape #1335 was filed under — a wait blamed for an add that never registered — on the surface the click repair does not reach.

Now repaired by dragComponentFromSidebar (commit dce327d). Re-measured:

Configuration	Result
bare drag + repaired click	4 / 5
repaired drag + repaired click	10 / 10 (6.6m)

Two things worth noting for review. The interval alone does not separate 9/10 from 10/10 — what carries the claim is the measured cause (the drag was observed swallowed, and re-issuing it once repairs it, same as #1304's click). And the gesture is re-issued rather than swapped for a click, because dragging out of the sidebar is an interaction Langflow ships and a spec that quietly stops exercising it stops covering it.

Orphans after those 10 runs: 0 test_server_*, 0 New Flow*.

[rafaelgiln]

The impacted-specs lane, run locally (GitHub Actions is in a major_outage)

pr-validation.yml's E2E job never ran — every workflow in this repo has been queued with zero runners since ~17:00 UTC. Since this PR changes a primitive reached by 34 call sites across 27 spec files, "typecheck is clean" is not evidence about those files, so the same selection the lane would make was resolved and run here instead.

scripts/impacted-specs-by-import.mjs on this diff selects 28 specs, 27 of them @stable, 0 dropped by the cap. All 28 were run against nightly 1.12.0.dev18, --workers=1 --retries=0:

94 passed, 1 failed, 1 skipped  (14.6m)

• 1 skipped — change mode of MCP tools, the test.fixme quarantined for [Daily #1258] mcp-server — GET /api/v2/mcp/servers times out when changing tool mode (recurrent 3×, load/reachability) #1266. Not this PR's.
• 1 failed — server-everything, i.e. [Daily #1330] mcp-server — the "Add MCP Server" button never renders for the server-everything Streamable-HTTP case (recurrent 2×) #1332. Details below.
• The four llm-agents/* specs ran rather than skipping: this repo's OpenAI key now reports You have no credits remaining (10 of 41 candidates, same drain as the 2026-08-04 CI run), and .env is still pinned to openai, so they were run under a per-run override MODEL_TEST_PROVIDER=anthropic MODEL_TEST_ID=claude-haiku-4-5. Without it they would have test.skip()d and this lane would have been green by absence.

Orphans after the run: 0 test_server_*, 0 New Flow*.

Correction to an earlier note on #1332

The PR body says the failure point "splits cleanly by side" between origin/main (the add-mcp-server-button visibility check) and this branch (the toolsCount poll), and records the cause as not established. It does not split by side. In this run, on this branch, it failed at the add-mcp-server-button check — element(s) not found after 15 s, #1332's exact signature, the same place origin/main fails.

So the point of failure is state-dependent, which was the hypothesis that could not be supported before and now can: line 1207 uses isVisible({ timeout: 15000 }), and Playwright ignores that option — the same defect this PR fixes in openAddMcpServerModal. The probe returns in ~1 ms, so which of the two sidebar entry points has painted at that instant decides whether the modal opens at all. Worth carrying into #1332: the fix there is likely the same shape as the one here, and the toolsCount variant is only what you see when the earlier check happens to win the race.

The PR body has been left as written and is corrected by this comment rather than edited over, so the earlier claim and its refutation both stay on the record.