[Daily #1121] upload-via-component: uploaded file item never renders — getByTestId('file-item-test-file') not found (recurrent flake, 2×)

[Victor-w-Madeira]

Spun out of daily-failure triage #1121 (run 30534416609, 2026-07-30). 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

In the file-management modal of the Read File component, the uploaded file item never renders: expect(getByTestId('file-item-test-file')).toBeVisible() fails after 15 s. Recovered on retry (1 failed attempt of 2). Same-signature recurrent across the dailies of 2026-07-23 and 2026-07-30.

Spec (line)	Waits for	Signature
tests-automations/regression/core-functionality/knowledge-ingestion-management/upload-via-component.spec.ts:68 ("upload a file through the Read File component and read its content")	getByTestId('file-item-test-file') to be visible (15 s)	Error: expect(locator).toBeVisible() failed

Why these failures are one cause

Single test, single signature — no grouping claim. Filed on its own because it is a file-management rendering wait, distinct from every other flake in the run.

Preliminary read (descriptive — NOT a verdict)

The spec already gates on the upload completing server-side — it awaits a POST /api/v2/files response with a < 300 status before touching the item — so a premature click on an unfinished upload (the flake this spec was previously hardened against) is not the obvious reading anymore. What is left to distinguish: whether the file list simply does not refresh after the successful POST, whether the item renders under a different test id than the one derived from the asset name, or whether the modal's list is paginated/filtered such that the new item is off-screen. Descriptive only — no cause asserted.

Investigation directive

1. Reproduce at --retries=0 against the current nightly and establish a rate; the two recorded hits are a week apart, so budget for repetition.
2. From the trace of the failing attempt, confirm the POST /api/v2/files response was 2xx and read the body — then check whether the subsequent list fetch (GET /api/v2/files) contains the file.
3. If the file is in the API response but not in the DOM, the defect is the modal's list rendering/refresh; if it is in the DOM under a different test id, the defect is the locator.
4. Decide whether the spec should wait on the list fetch rather than on the item, and whether the item's test id is derived from data the test controls.

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.

Flake signal

This test is confirmed recurrent (dailies 2026-07-23, 2026-07-30). As prevention it was quarantined at triage — @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/core-functionality/knowledge-ingestion-management/upload-via-component.spec.ts (test at line 68)

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

[Victor-w-Madeira]

Quarantined at triage in PR #1127 — @stable removed and test.fixme added at tests/tests-automations/regression/core-functionality/knowledge-ingestion-management/upload-via-component.spec.ts:68. Lifting it is a deliverable of this issue.

[Victor-w-Madeira]

Root cause found and fixed — PR #1140. Two corrections to this issue's body, both from the run artifacts of 30534416609:

1. The failure is not in the file-management modal. In results.json the step upload the local file through the file-management modal passed in 1065 ms; the failure is the next step, the file is attached to the component — upload-via-component.spec.ts:139, the node chip — element(s) not found after 15 s. The failure screenshot and ARIA snapshot show the modal closed and the Read File Files field empty ("Select files").
2. Not a same-signature recurrence. The 2026-07-23 failure of this spec was sidebar-search-input never visible during setup (line 81) — the [Daily #1057] sidebar-search-input never becomes visible after entering a blank flow — setup timeout across 4 specs (recurrent) #1063 cluster. 07-30 was the first occurrence of this signature, so the "recurrent flake, 2×" framing does not hold.

Cause: POST /api/v2/files enforces unique names with a prefix query (name LIKE '<stem>%'), so any residue row named test-file* in the shard's shared account renames the upload to test-file (1). The spec uploaded the fixed asset name and asserted file-item-test-file, a testid derived from the local name — the node chip then carries the renamed label and matches nothing, while the modal assertion still passes against the residue row (or the optimistic cache entry). Reproduced deterministically on 1.12.0.dev10 by seeding one test-file row.

Verdict: test defect — no product bug, nothing to file upstream. The fix uploads under a per-run unique name, derives the testids from the name the server returns, gates the confirm click on checkbox-<name> being checked, and replaces the name-prefix file cleanup (a cross-worker wipe, #465) with id-scoped deletion. Quarantine lifted and @stable restored in the same PR.