Concurrent flow creation answers 500 locally, and the failure surfaces as a hidden sidebar

[Victor-w-Madeira]

Found while validating #1112. Not a CI risk at the current worker setting — see "Severity" below before spending time on it.

What happens

Running api/flows/api-component-regression.spec.ts at Playwright's local default worker count starts all 5 tests at once. Each one creates two flows (awaitBootstrapTest and the blank-flow click each POST their own), so ~10 POST /api/v1/flows/ land on a single Langflow instance within a second or two. Some of them answer 500:

🚨 Backend Error: 500 Internal Server Error - http://localhost:7860/api/v1/flows/
   Response: {"detail":"An internal error occurred while creating the flow."}

The failure that follows is not at the POST — the fixture logs it and moves on. It surfaces one step later in addApiRequestComponent, where the editor mounts without a usable sidebar:

TimeoutError: page.waitForSelector: Timeout 10000ms exceeded.
  - waiting for locator('[data-testid="sidebar-search-input"]') to be visible
  - 8 × locator resolved to hidden <input ... data-testid="sidebar-search-input" ...>

So the reported failure names a hidden sidebar, and the actual cause — a flow that was never created — is three log lines up.

Measurements

Langflow Nightly 1.12.0.dev9 (local, SQLite), 10-core machine, full file, --retries=0:

Workers	Result	Backend 500s
1	5 passed (3 consecutive runs)	0
2 (what CI uses)	5 passed	1 logged, no failure
5 (local default: workers: undefined → cores/2)	1 failed / 4 passed, repeated	3–5

Reproduced identically on clean main with no local changes, so it is not from #1107/#1111/#1112.

Severity — deliberately low

playwright.config.ts:88 pins workers: 2 in CI, and at 2 workers this file is green. The failure only appears at the local default. So this costs local developer time, not daily signal: someone running the full file locally sees a red @release test that is not real, and the message points at the wrong thing.

That is also the argument for not chasing it hard. It is filed so the next person who hits it does not re-derive it.

What is actually worth doing

1. Cheapest, and the only part with clear value: make the cause legible. addApiRequestComponent should fail naming the missing flow rather than the hidden sidebar — the accumulator in this file already knows whether a 201 was ever captured.
2. Consider whether the double flow creation is needed at all. Every test here creates two flows because awaitBootstrapTest POSTs one and then blank-flow POSTs another. Halving that halves the write burst. This is suite-wide, not local to this file, so it is a shared-helper change and would need its own issue.
3. Do not raise CI workers on this file until the above is understood.

Related, not duplicate

• Relieve within-shard contention on the heavy shard (real-LLM specs co-locate under one backend) #950 — within-shard contention on the heavy shard. Different mechanism: real-LLM build/run serialization, not flow-creation writes.
• Investigate: broad agent/playground execution flakiness under the daily's parallel CI load (gated on clean baseline post-#772) #773 — broad agent/playground flakiness under parallel CI load.
• daily-stable: choose and benchmark the lever that relieves the mid-run worker wedge #1077 — the mid-run worker wedge.
• loadTemplateByName is not concurrency-safe — random template spec fails in setup and leaks a flow #1002 — loadTemplateByName is not concurrency-safe. Closest in kind (a concurrency-unsafe setup path that leaks a flow), but a different endpoint and a different failure.

Out of scope

Whether Langflow itself should answer 500 rather than serializing or retrying the write. The response body is generic ("An internal error occurred while creating the flow."), so attributing it would need the backend log — worth doing only if this is ever pursued upstream.