[Daily #1330] auto-save-off — reopening the just-created flow's card intermittently times out at 45 s (recurrent 2×)

[Victor-w-Madeira]

Spun out of daily-failure triage #1330 (run 31093877484, 2026-08-06). Recurrent flake (same signature on the 2026-07-22 and 2026-08-06 dailies), so it is filed rather than noted — CONTRIBUTING.md → Triage protocol, step 2.

Upstream: not filed

Symptom

The @stable manual-save test flaked: an attempt failed with locator.click: Timeout 45000ms exceeded reopening the flow it had just created, via its list-card-open-button on the flows list; the retry passed. 45 s is already a generous budget, so this is not a marginally-tight wait.

Spec (line)	Waits for	Signature
tests/tests-automations/regression/flow-functionality/auto-save-off.spec.ts:59 ("user should be able to manually save a flow when the auto_save is off")	list-card-open-button on the just-created flow → clickable (45 s)	TimeoutError: locator.click: Timeout 45000ms exceeded.

Why these failures are one cause

Single test. Recurrence is same-signature on 2026-07-22 and 2026-08-06; the same test also has hits on 2026-07-15 and 2026-07-16 under a different signature, which are a different cause and are not counted toward the criterion.

Preliminary read (descriptive — NOT a verdict)

Descriptive observations only:

• The two same-signature occurrences are 15 days apart, which is what the 30-day window exists to catch and what a "two consecutive runs" rule would have missed.
• The wait is 45 s on a card that the test itself just created, so a slow list render alone is a strained explanation; a card that never reaches a clickable state (or reaches it under a different identity than the locator expects) fits better.
• Known related history worth checking against, not asserted as the cause: the flows-list card once had its click surface broken by an upstream a11y change (flow-name-div made pointer-events-none), which is why the suite opens flows via list-card-open-button at all.
• The suite's backend liveness section for this run recorded no measured outage, but discarded 19 single-probe failures as blips, so backend latency cannot be excluded.

Investigation directive

All paths must be investigated independently, and the product is the prime suspect first: on the current nightly, create a flow with auto-save off and confirm the resulting list card reliably reaches a clickable state — including whether the card is fully rendered before the list settles, and whether anything overlays it. A "raise the timeout" or "the locator drifted" explanation may be accepted only after confirming this does not mask a regression in how a newly created flow lands in the list. Then the test path (wait on the card's state rather than clicking into a timeout), then the environment.

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.

[Victor-w-Madeira]

Quarantined as prevention in PR #1338 — @stable removed and test.fixme added at tests/tests-automations/regression/flow-functionality/auto-save-off.spec.ts:59, so the test stops running in every context (daily, PR impacted-specs gate, full suite) until this issue is worked.

Lifting the quarantine (remove test.fixme + restore @stable, re-validated per CONTRIBUTING.md) is a deliverable of this issue.

[Victor-w-Madeira]

Root cause confirmed — test defect, not a product regression. Fix in PR #1339.

The spec was driving another worker's flow. It re-opened "the just-created flow" by clicking the first list-card whose name contained "New Flow", and Langflow names every blank flow New Flow/New Flow (N) — so under fullyParallel the list holds one per worker. Proved on nightly 1.12.0.dev18 by logging the page's own network: the page created 8e767306 and ee8e0ab9, and the re-open landed on 164b3c19, an id it never created. When that flow's real owner ran its id-scoped cleanup, the save PATCH came back 404, the editor never navigated back to the list, and the following re-open burned its full 45 s on a card with no reason to exist.

That is also what the 2026-08-06 artifact shows, and it answers the issue's read of it: the failure screenshot is the canvas, not the flows list — flow saved, no dialog — with 404 Flow not found on both /api/v1/flows/{id} and its /events poll in the advisory log. So the card never "failed to become clickable"; the test was somewhere else entirely. Reproduced 3/8 at --workers=4 --retries=0, same signature and line.

The product was checked first, as the directive asked, and cleared on this path: creating a flow with auto-save off and re-opening its card is reliable, nothing overlays it, and the exit/save behaves. Two adjacent findings decided the shape of the fix:

• Scoping the card by id does not fix it. The flows list is paginated at 12 and ordered by updated_at DESC, and under load this test's own card is routinely off page 1 (measured at the failure: 12 of 12 slots held by fresher flows). The old spec's "success" therefore depended on some other worker's blank flow being on top — which also made the discard assertion (div-generic-node count === 0) vacuous whenever it opened a stranger's fresh blank flow. This was worse than a flake.
• The id must be read after the blank-flow navigation. awaitBootstrapTest reaches the templates modal through "New Flow", which parks the page on a placeholder flow Langflow deletes as soon as the modal navigates elsewhere — Create agent-tool-name-validation.spec.ts — invalid tool name blocked with clear message #490/Validate & promote flow settings — §12.2 #681 from the other side.

Fix: re-open by id/URL (waiting on GET /api/v1/flows/{id} and the canvas mount), plus an explicit assertion at every exit that the editor was actually left. That second half is the attribution this flake lacked — verified by forcing the save PATCH to 500, which now fails at the exit step instead of 45 s later on an unrelated locator.

Quarantine lifted in the PR (test.fixme removed, @stable restored). Validation: 5/5 serial, 8/8 under the identical burst that produced 3/8 failures before, --trace=on clean, zero backend errors, zero flow leak, three executed force-fails.

Latent hazard from the same pattern in mcp/server/mcp-server.spec.ts (lines 963, 1083) filed separately as #1340 — not #1335, which is a different file and signature.