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
The keyboard path into the component sidebar broke, with two different symptoms across the three attempts:
- Attempt 1 — after clicking the canvas and pressing
/, expect(getByTestId('sidebar-search-input')).toBeFocused() failed within 10 s: the shortcut did not move focus into the search field.
- Attempts 2–3 — the search field was focused and the
chat filter applied, but the Tab walk never reached the Chat Input card: "input_output_chat input_draggable" never received focus within 10 Tab presses (last focused: add-component-button-valkey-chat-memory).
| Spec (line) |
Waits for |
Signature |
tests-automations/regression/ui-ux/keyboardComponentSearch.spec.ts:79 ("user can search and add components using keyboard shortcuts") |
the Chat Input card to receive focus within 10 Tab presses (attempt 1: the search input to be focused after pressing '/') |
Error: "input_output_chat input_draggable" never received focus within 10 Tab presses (last focused: add-component-button-valkey-chat-memory) |
Why these failures are one cause
One test, filed once, even though the recorded last errors differ between attempt 1 and attempts 2–3. Both symptoms sit on the same keyboard-navigation path through the sidebar search, and splitting them would create two issues whose investigation is the same session. The two symptoms are reported separately above so neither is lost if they turn out to be independent.
Preliminary read (descriptive — NOT a verdict)
The last-focused element in attempts 2–3 is add-component-button-valkey-chat-memory — a Valkey Chat Memory card. That is a plausible sign that the set (or the order) of components matching the query chat in the current nightly's sidebar is not what the 10-press Tab budget was calibrated against: with more matches, or with bundle sections ordered ahead of the core Input/Output section, the Chat Input card can sit beyond press 10 while nothing is actually broken in the product. The attempt-1 symptom is different in kind — / not reaching the field at all — and could be a focus/timing issue after the canvas click, or a change to the shortcut binding. Neither reading is a verdict, and the two may have different causes.
Investigation directive
- Reproduce on the current nightly at
--retries=0, then dump the filtered sidebar for the query chat: which cards match, and in what DOM/tab order.
- Count the Tab presses actually needed to reach the Chat Input card. If it is > 10, decide whether the fix is a larger budget or — better — focusing the target card directly instead of walking to it, and say why the walk is or is not the behaviour under test.
- Separately, verify the
/ shortcut still focuses sidebar-search-input from a freshly clicked canvas, and whether a wait is missing before the keypress.
- Confirm whether either symptom reproduces on a released Langflow image; a nightly-only regression in the shortcut binding is a product finding, a Tab-budget miscalibration is not.
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
The keyboard path into the component sidebar broke, with two different symptoms across the three attempts:
/,expect(getByTestId('sidebar-search-input')).toBeFocused()failed within 10 s: the shortcut did not move focus into the search field.chatfilter applied, but the Tab walk never reached the Chat Input card:"input_output_chat input_draggable" never received focus within 10 Tab presses (last focused: add-component-button-valkey-chat-memory).tests-automations/regression/ui-ux/keyboardComponentSearch.spec.ts:79("user can search and add components using keyboard shortcuts")the Chat Input card to receive focus within 10 Tab presses (attempt 1: the search input to be focused after pressing '/')Error: "input_output_chat input_draggable" never received focus within 10 Tab presses (last focused: add-component-button-valkey-chat-memory)Why these failures are one cause
One test, filed once, even though the recorded last errors differ between attempt 1 and attempts 2–3. Both symptoms sit on the same keyboard-navigation path through the sidebar search, and splitting them would create two issues whose investigation is the same session. The two symptoms are reported separately above so neither is lost if they turn out to be independent.
Preliminary read (descriptive — NOT a verdict)
The last-focused element in attempts 2–3 is
add-component-button-valkey-chat-memory— a Valkey Chat Memory card. That is a plausible sign that the set (or the order) of components matching the querychatin the current nightly's sidebar is not what the 10-press Tab budget was calibrated against: with more matches, or with bundle sections ordered ahead of the core Input/Output section, the Chat Input card can sit beyond press 10 while nothing is actually broken in the product. The attempt-1 symptom is different in kind —/not reaching the field at all — and could be a focus/timing issue after the canvas click, or a change to the shortcut binding. Neither reading is a verdict, and the two may have different causes.Investigation directive
--retries=0, then dump the filtered sidebar for the querychat: which cards match, and in what DOM/tab order./shortcut still focusessidebar-search-inputfrom a freshly clicked canvas, and whether a wait is missing before the keypress.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./focus failure and the Tab-walk exhaustion — either as one cause or explicitly as two.@stablerestored on the test (it was auto-removed by the daily workflow), re-validated perCONTRIBUTING.md.