[Daily #1057] sidebar-search-input never becomes visible after entering a blank flow — setup timeout across 4 specs (recurrent)

[Victor-w-Madeira]

Spun out of daily-failure triage #1057 (run 30444299314, 2026-07-29).

Upstream: not filed

Corrected 2026-07-30 from the run artifacts. The original body attributed this
flake to the error-feedback selector and claimed a single test with no grouping. The
JSON reports of all three runs show the timeout is in setupChatFlow, waiting for
the sidebar search input to become visible — before the error is ever provoked — and
that three further specs hit the same condition. Symptom, grouping, preliminary read
and investigation directive were rewritten accordingly; see the correction comment for
the raw call logs.

Symptom

Four @stable specs flaked (recovered on retry) with the same shape — [data-testid="sidebar-search-input"] is present in the DOM but never becomes visible, so the sidebar-entry step of the setup times out. In every case the failure is in the setup that enters a blank flow and filters the sidebar, before the test's own subject is exercised.

Spec (line)	Waits for	Signature
tests/tests-automations/regression/ui-ux/execution-error-notification.spec.ts:54 ("executing flow with server error shows error feedback", declared at :139)	waitForSelector('[data-testid="sidebar-search-input"]') — state visible, 30 s	TimeoutError: page.waitForSelector: Timeout 30000ms exceeded.
tests/tests-automations/regression/core-functionality/playground/playground-clear-history.spec.ts:43 ("clear chat on Default session must remove messages but keep the session", declared at :110)	getByTestId('sidebar-search-input').fill(...) — 20 s	TimeoutError: locator.fill: Timeout 20000ms exceeded.
tests/tests-automations/regression/core-components/api-request-component-regression.spec.ts:100 ("API Request component — non-2xx HTTP response propagates status_code without crashing", declared at :560)	getByTestId('sidebar-search-input').fill(...) — 20 s	TimeoutError: locator.fill: Timeout 20000ms exceeded.
tests/tests-automations/regression/core-functionality/playground/output-modal-copy-button.spec.ts:67 ("copy button copies Chat Input output and toggles Check icon", declared at :39)	getByTestId('sidebar-search-input').fill(...) — 20 s	TimeoutError: locator.fill: Timeout 20000ms exceeded.

Occurrences by run:

Run	Date	Specs hit
30444299314	2026-07-29	execution-error-notification, playground-clear-history
29822019255	2026-07-21 (10:23)	execution-error-notification, api-request-component-regression
29832136328	2026-07-21 (12:55)	output-modal-copy-button (execution-error-notification passed)

The 12:55 run of 07-21 is not the entry recorded in reports/daily-history.jsonl for that date (only 29822019255 is), so its signature is cited from the run's JSON artifact rather than the history row.

The line numbers in the first column are the failing lines; the history rows key on the test() declaration line, which is what the original body carried as the failure site.

Why these failures are one cause

The shared dimension is the element and its state, not the signature: all four resolve [data-testid="sidebar-search-input"] successfully and then time out because it is not visible.

• execution-error-notification uses page.waitForSelector (default state visible), and the call log records 4 × locator resolved to hidden <input … data-testid="sidebar-search-input" …>.
• The other three use locator.fill, whose actionability check is visible, enabled and editable; their call logs record repeated element is not visible against the same resolved input — playground-clear-history logs 2 ×, then element was detached from the DOM, retrying, then a further 39 × invisible over the 20 s.

The signatures differ (page.waitForSelector 30 s vs. locator.fill 20 s) purely because the specs use different Playwright APIs against the same element with different timeouts. TimeoutError: locator.fill: Timeout 20000ms exceeded. is generic on its own, so the grouping does not rest on it: the second shared dimension is the identical testid plus the identical actionability reason (not visible on a resolved element) plus the identical step (entering a blank flow, then filtering the sidebar).

All four specs are also structurally identical at the failure point: awaitBootstrapTest → click blank-flow → wait on / fill sidebar-search-input.

Cross-day recurrence is a property of this condition, not of any single spec: it appears on 2026-07-21 and 2026-07-29, and on 07-21 it hit two different specs in two different runs while execution-error-notification passed in one of them.

Preliminary read (descriptive — NOT a verdict)

The 2026-07-29 run was a mass-failure day (10 hard + 12 flaky, guard threshold 5 crossed). The triage verdict on the day itself was environmental for the hard failures: 6 of the 10 are a 20 s timeout on GET /api/v1/auto_login in shards where every provider was green and the post-collect-models health gate had already passed (#1030), and two shards executed zero tests after a credentials-preflight abort (#1058). That verdict governs the hard failures and does not extend to this cluster.

The 2026-07-21 10:23 occurrence is on a run that recorded only 3 hard failures and did not trip the guard, so the condition is not confined to mass-failure days.

Two observations bound the search, both descriptive:

• The failure is in setup, not in the subject under test. For execution-error-notification specifically, the provoked 503 is served by page.route(…).fulfill() — resolved in the browser, never reaching the backend — and that route is registered only after setupChatFlow and openPlayground return. The provoked request therefore cannot be the thing that hangs. What does reach the backend before the failing wait is the blank-flow bootstrap and the sidebar's component load, which is where an instance-saturation influence would have to act.
• The element is not missing and the testid has not drifted. It resolves every time; it stays invisible. Whatever renders the sidebar collapsed / zero-size, or remounts it invisible (element was detached from the DOM, retrying), is the surface to look at — not the selector.

Investigation directive

Investigate all paths independently, product as prime suspect first:

1. On the current nightly, confirm whether the sidebar reliably becomes visible after entering a blank flow — and determine what state the sidebar is in when it does not (collapsed, zero-width, mid-remount, behind a still-closing templates modal). Rule out a Langflow regression in the flow-page sidebar mount before concluding anything test-side.
2. Establish a rate at --retries=0. The signal is load-dependent (it appeared in runs of 236–410 tests in parallel and recovered on retry every time), so an isolated local run coming back green does not clear the condition — reproduce under parallel load, or from the CI lane.
3. From the 07-21 and 07-29 traces, determine whether the sidebar's component-list request had returned by the time the wait started, and whether the remount recorded in playground-clear-history correlates with a backend response arriving late.
4. Only after ruling out a product regression, consider: (a) transient saturation → prove on 3 environments and restore; (b) wait-strategy fragility → the four specs each hand-roll the sidebar-entry wait, so decide whether the deterministic observable belongs in a shared helper rather than being re-derived per spec.

Note that the original directive's items on the provoked request hanging, on error-feedback selector drift, and on replacing the live failing execution with a deterministic error injection are moot: the run is already deterministic and client-side mocked, and the failing selector is not the error-feedback one.

Deliverables (Done when)

• Root cause confirmed (product regression vs. test/wait-strategy vs. environment) with evidence on the current nightly, for the shared sidebar-entry condition rather than per spec.
• Each of the four specs passes reliably (multiple clean --retries=0 runs, under parallel load), fixing the sidebar-entry wait as needed.
• Decision recorded on whether the fix is spec-local or belongs in a shared sidebar-entry helper, given that the other three specs are unquarantined and still @stable.
• Quarantine lifted in the fix PR — remove test.fixme and restore @stable on tests/tests-automations/regression/ui-ux/execution-error-notification.spec.ts, re-validated per CONTRIBUTING.md. Force-fail scope is the whole file: all three of its tests share setupChatFlow.
• 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.

Flake signal

The condition is confirmed recurrent (dailies 2026-07-21 and 2026-07-29). One spec was quarantined at triage in PR #1064 — @stable removed and test.fixme added — so it stops running in every context (daily, PR impacted-specs gate, full suite) until this issue is worked:

• tests/tests-automations/regression/ui-ux/execution-error-notification.spec.ts (test declared at line 139, fails at line 54)

Lifting that quarantine after the fix (remove test.fixme + restore @stable) is a deliverable of this issue.

Two scope notes on the quarantine, both open decisions for whoever works this:

• It does not cover the sibling tests in the same file. executing flow with network error shows error feedback (declared at line 105) is still @stable and calls the same setupChatFlow, so it hits the identical line-54 wait. flow run button shows loading state during execution (line 175) likewise.
• The other three specs are not quarantined. Each has a single recorded occurrence, so the per-spec flake criterion does not call for quarantine; what is recurrent is the shared condition. They remain @stable:
  • tests/tests-automations/regression/core-functionality/playground/playground-clear-history.spec.ts (test at line 110)
  • tests/tests-automations/regression/core-components/api-request-component-regression.spec.ts (test at line 560)
  • tests/tests-automations/regression/core-functionality/playground/output-modal-copy-button.spec.ts (test at line 39)

[daniellicnerski1]

Body corrected from the run artifacts — 2026-07-30

The opening post attributed this flake to the error-feedback selector and stated "single test, single signature — no grouping claim". Both are wrong. Evidence below, from the playwright-json-daily-* artifacts of the three runs; the previous reading is superseded, not deleted, so the reasoning stays auditable.

1. The timeout is in the setup, not in the error-feedback assertion

tests/tests-automations/regression/ui-ux/execution-error-notification.spec.ts — run 30444299314, attempt 0 failed in 35.8 s, attempt 1 passed in 13.4 s:

TimeoutError: page.waitForSelector: Timeout 30000ms exceeded.
Call log:
  - waiting for locator('[data-testid="sidebar-search-input"]') to be visible
    4 × locator resolved to hidden <input value="" type="search" … data-testid="sidebar-search-input"
        class="nopan nodelete nodrag noflow primary-input !placeholder-transparent pl-9 w-full rounded-lg bg-background text-sm"/>

The reported error location is execution-error-notification.spec.ts:54, inside the setupChatFlow helper:

 53 |   // Add ChatOutput first (hover → click add button)
>54 |   await page.waitForSelector('[data-testid="sidebar-search-input"]', {
    |              ^
 55 |     timeout: 30000,

Identical location and call log on run 29822019255 (2026-07-21). The 137 the original body carried is the test() declaration line as recorded in reports/daily-history.jsonl, not the line that failed.

This matters because the failure happens before the test's subject exists: page.route(WORKFLOWS_ENDPOINT, …) — the mocked 503 — is registered only after setupChatFlow and openPlayground return, and route.fulfill() is served in the browser and never reaches the backend. So the original preliminary read's hypothesis ("on a saturated or wedged backend the provoked request may hang instead of erroring") cannot apply to the request it names.

2. Three further specs hit the same condition

Scanning all results in the three runs for the same testid:

Run	Date	Spec	Failing line	Signature (verbatim, from history where recorded)
30444299314	07-29	tests/tests-automations/regression/core-functionality/playground/playground-clear-history.spec.ts (test at :110)	:43	TimeoutError: locator.fill: Timeout 20000ms exceeded.
29822019255	07-21 10:23	tests/tests-automations/regression/core-components/api-request-component-regression.spec.ts (test at :560)	:100	TimeoutError: locator.fill: Timeout 20000ms exceeded.
29832136328	07-21 12:55	tests/tests-automations/regression/core-functionality/playground/output-modal-copy-button.spec.ts (test at :39)	:67	TimeoutError: locator.fill: Timeout 20000ms exceeded. (from the run artifact — this run is not the 07-21 entry in daily-history.jsonl)

In run 29832136328, execution-error-notification passed and only output-modal-copy-button flaked — the condition recurs independently of any one spec.

locator.fill's actionability check gives the reason explicitly (playground-clear-history, run 30444299314):

  - waiting for getByTestId('sidebar-search-input')
    - locator resolved to <input value="" type="search" … data-testid="sidebar-search-input" …/>
    - fill("chat output")
  - attempting fill action
    2 × waiting for element to be visible, enabled and editable
      - element is not visible
    - retrying fill action
    …
  - element was detached from the DOM, retrying
    - locator resolved to <input … data-testid="sidebar-search-input" …/>
    …
    39 × waiting for element to be visible, enabled and editable
       - element is not visible

Same element, same reason (not visible on a resolved element), same step (enter blank flow → filter sidebar). The differing signature strings are just page.waitForSelector/30 s vs. locator.fill/20 s — different APIs against the same element. The remount (element was detached from the DOM, retrying) followed by continued invisibility is the most specific lead in the artifacts.

3. What this changes in the issue

• Symptom — now names [data-testid="sidebar-search-input"] and the failing lines, with all four specs in backticked repo-relative form.
• Why these failures are one cause — the grouping is now argued on the shared element + actionability reason + step, explicitly noting that locator.fill: Timeout 20000ms exceeded. is too generic to group on alone.
• Preliminary read — the environmental vector is relocated from the (client-side mocked) provoked request to the blank-flow bootstrap and the sidebar's component load, which do hit the backend before the failing wait.
• Investigation directive — items on the provoked request hanging, on error-feedback selector drift, and on switching to deterministic error injection are recorded as moot; replaced with confirming the sidebar mount on the current nightly, establishing the rate under parallel load, and reading the traces for a late component-list response.
• Flake signal — records that PR fix(quarantine): quarantine four recurrent flakes from the 2026-07-29 daily (#1057) #1064's quarantine covers one test only, while its two file siblings (:105, :175) share setupChatFlow and stay @stable, and that the other three specs are unquarantined (one recorded occurrence each; what is recurrent is the shared condition).

No test code was changed by this correction.

4. Open question for whoever works this

Whether this should stay one issue or split: the four specs share a condition but the fix may be a shared sidebar-entry helper rather than four local waits, and the three siblings are still @stable and unprotected. Folding them in here follows the guard-day grouping rule ("all sidebar-entry timeouts" into one issue); the alternative is a parent issue for the condition with this one scoped to its spec.

[Victor-w-Madeira]

Evidence from another run — a 5th spec, same signature. While working #1125 I pulled the JSON report of the 2026-07-23 daily (run 29998922242) and upload-via-component.spec.ts failed there with this cluster's signature, not with its own:

Locator: getByTestId('sidebar-search-input')
Expected: visible — Error: element(s) not found
at .../knowledge-ingestion-management/upload-via-component.spec.ts:81
step: open a blank flow (30338 ms) — recovered on retry

Note the call log line 3 × locator resolved to <input ... data-testid="sidebar-search-input" ...>: the element is in the DOM and never becomes visible — the same shape as the four specs already listed here.

That occurrence was attributed to #1125 at the triage of daily #1121 (grouped by spec file rather than by signature); it belongs here. Filing it as context only — no change requested on this issue.