[Daily #1361] project sidebar — every project is addressed by name, but the entry no longer carries a name-derived testid (7 tests, 4 specs)

[Victor-w-Madeira]

Spun out of daily-failure triage #1361 (run 31163810520, 2026-08-07). Filed against the Guard-Tripped Rule's today-only-collateral default — see Preliminary read.

Upstream: not filed

Symptom

Seven @stable tests hard-failed with one shape: a project the backend confirms exists (POST /api/v1/projects → 201) never resolves in the home sidebar under the testid the suite builds from its name. Every one failed on all three attempts, each attempt creating a fresh project, across worker indices 2–17 and outside the run's single 108 s outage window.

The suite addresses a project by name in two places, and both are in the failing call logs: sidebar-nav-<name> and more-options-button_<slugified name>.

Spec (line)	Waits for	Signature
tests/tests-automations/regression/core-functionality/project-management/folder-deletion-integrity.spec.ts:166 ("deleting a folder should update the folder list immediately")	getByTestId('sidebar-nav-del-integrity-<ts>')	Error: expect(locator).toBeVisible() failed
tests/tests-automations/regression/core-functionality/project-management/folder-deletion-integrity.spec.ts:227 ("deleting one folder should not affect other folders")	getByTestId('sidebar-nav-New Project')	Error: expect(locator).toBeVisible() failed
tests/tests-automations/regression/core-functionality/project-management/folder-deletion-integrity.spec.ts:307 ("creating a new folder after deletion should work correctly")	getByTestId('sidebar-nav-New Project (3)')	Error: expect(locator).toBeVisible() failed
tests/tests-automations/regression/core-functionality/project-management/folder-crud.spec.ts:26 ("creates, renames and deletes an empty project folder via the UI")	getByTestId('sidebar-nav-New Project')	Error: expect(locator).toBeVisible() failed
tests/tests-automations/regression/core-functionality/project-management/folder-crud.spec.ts:86 ("deleting a folder that contains a flow removes the flow with it")	getByTestId('sidebar-nav-crud-del-folder-<ts>')	Error: expect(locator).toBeVisible() failed
tests/tests-automations/regression/core-functionality/project-management/bulk-actions.spec.ts:8 ("user should be able to select flows with different methods and perform bulk actions")	getByTestId('sidebar-nav-bulk-actions-folder-<ts>')	TimeoutError: locator.click: Timeout 20000ms exceeded.
tests/tests-automations/regression/mcp/server/mcp-server-starter-projects.spec.ts:61 ("user must be able to see starter projects for mcp servers")	getByTestId('more-options-button_new-project').last()	TimeoutError: locator.click: Timeout 20000ms exceeded.

Why these failures are one cause

The shared dimension is how the suite addresses a project, not the assertion. The signatures differ — five are toBeVisible() failed and two are locator.click: Timeout — and they are grouped anyway because the locator underneath is the same construction in both forms:

• sidebar-nav-${name} — tests/helpers/flows/create-project-through-sidebar.ts:40,57,60, tests/pages/MainPage.ts:95,103,116,129, and inline in all four specs
• more-options-button_${slugified name} — tests/pages/MainPage.ts:96, tests/helpers/filesystem/clean-old-folders.ts:18, and inline in folder-deletion-integrity.spec.ts and mcp-server-starter-projects.spec.ts

Every failing wait is one of those two. No spec-level change is common to the four files; three of them do not import each other at all. The one thing they share is the addressing scheme, and the run before this one (2026-08-06) had zero failures in any of them.

The two locator.click: Timeout entries are not wedge collateral: locator.click is deliberately absent from scripts/lib/infra-signature-patterns.json because a real breakage produces it too, and here the click target is the very testid the other five wait on.

Preliminary read (descriptive — NOT a verdict)

This surfaced on a mass-failure day — 8 hard failures against the guard threshold of 5, so daily-stable.yml tripped the mass-failure guard and auto-removed @stable from nothing. The run also carried a confirmed backend outage (108 s on shard 1, 09:07:57→09:09:46 UTC). Neither explains this cluster: it survived every retry, spans both shards and worker indices 2–17, and sits outside the outage window — so the triage's verdict on the day is that it was not environmental, and these seven were quarantined manually (the workflow did not).

Lead to rule out first — stated as a hypothesis, not a cause. Upstream commit 23f91d8587 (fix(authz): support scoped project visibility, langflow-ai/langflow#14429, 2026-08-05) changes both testids in src/frontend/src/components/core/folderSidebarComponent/:

  // components/sideBarFolderButtons/index.tsx
- data-testid={`sidebar-nav-${item.name}`}
+ data-testid={`sidebar-nav-${item.id}`}

  // components/sideBarFolderButtons/components/select-options.tsx
- "more-options-button" + `_${convertTestName(item?.name ?? "")}`
+ data-testid={`more-options-button_${item.id}`}

The commit is on release-1.12.0 — the line langflowai/langflow-nightly:latest is cut from — and not on main. That is consistent with the failure landing on 08-07 and not on 08-06, but the image the 08-06 run actually pulled has not been checked, so the correlation is unconfirmed.

A second-order effect worth measuring rather than assuming: cleanOldFolders addresses the kebab the same way, so if it stopped deleting, leftover projects accumulate within a run — which is what the retries show (New Project → New Project (5) across six attempts).

Scope is wider than the seven tests that failed. tests/pages/MainPage.ts (deleteProject, clickProject, uploadFlowByDragDrop), tests/helpers/flows/create-project-through-sidebar.ts, tests/helpers/filesystem/clean-old-folders.ts, plus tests/tests-automations/regression/core-functionality/project-management/folder-drag-drop-flow.spec.ts and tests/tests-automations/regression/core-functionality/project-management/flow-navigation-between-folders.spec.ts carry the same addressing. The last two carry no @stable, so they never ran in this daily.

Investigation directive

Investigate independently, product as prime suspect first. (a) On the current nightly, confirm whether a project entry still renders a name-derived data-testid at all — read the DOM, do not infer it from the commit above. (b) If the testid is now the project id, decide whether that is a product regression (a11y/automation contract broken for users of the id) or an internal rename the suite must adapt to — the two have different homes, and only the second is a suite fix. (c) Rule out the alternative readings the diff does not cover: the same commit wraps the entry in ProjectRenamePermission, so confirm the entry is not being gated away by an authz check rather than merely renamed. (d) Measure whether cleanOldFolders still deletes; if not, the leftover accumulation is a second defect riding on the first.

Whichever way (b) lands, the fix belongs in the shared layer (MainPage.ts, create-project-through-sidebar.ts, clean-old-folders.ts) before the four specs — addressing by the id the create response already returns removes the ambiguity #1023 documented, rather than trading one name for another.

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.
• The two non-@stable specs carrying the same addressing (tests/tests-automations/regression/core-functionality/project-management/folder-drag-drop-flow.spec.ts, tests/tests-automations/regression/core-functionality/project-management/flow-navigation-between-folders.spec.ts) are fixed in the same PR — they are latently broken and invisible to the daily.
• tests/helpers/filesystem/clean-old-folders.ts is confirmed to actually delete again, measured, not assumed — a silently-failing cleanup is what let leftovers accumulate inside a single run.
• If the verdict is a product regression, a row is owed in REGRESSIONS.md and an upstream ticket filed; if it is an internal rename, say so explicitly here so the next reader does not re-open the same question.

[Victor-w-Madeira]

Correction to the Preliminary read — the leftover accumulation is not evidence of a broken cleanup

The body says the New Project → New Project (5) progression across retries is what a non-deleting cleanOldFolders would show. That attribution is wrong and would send the investigation down a dead end.

cleanOldFolders has exactly one call site in the suite:

• tests/tests-automations/regression/mcp/server/mcp-server-starter-projects.spec.ts:73

It is not a shared teardown and it does not run for the four project-management specs at all. The escalating names are fully explained by the retries themselves: each of the six attempts across folder-crud.spec.ts:26 and folder-deletion-integrity.spec.ts:227,307 creates its own project via the sidebar button, and Langflow de-duplicates New Project server-side. Nothing needs to have failed to delete for that sequence to appear.

What still holds: tests/helpers/filesystem/clean-old-folders.ts:18 genuinely builds more-options-button_${convertTestName(name)}, so it carries the same addressing as everything else in this issue and is in scope for the fix. The deliverable stays. What does not hold is treating the leftover names as a symptom of it — they are a symptom of retrying, and measuring the cleanup expecting to find the cause of the accumulation would waste the effort.

The mcp-server-starter-projects.spec.ts:61 test that owns that call site is quarantined under this issue, so the helper is currently unexercised either way.

[Victor-w-Madeira]

Verdict: internal rename of an automation hook — NOT a product regression

Answering (b) explicitly, so the next reader does not re-open the question.

(a) The testid, read from the DOM on the current nightly

Measured on langflowai/langflow-nightly:latest = 1.12.0.dev20, reading the live home sidebar rather than inferring from the commit:

entry   data-testid="sidebar-nav-<uuid>"           id="sidebar-nav-<uuid>"
kebab   data-testid="more-options-button_<uuid>"   aria-label="Options for <name>"
wrapper data-project-id="<uuid>"

No name-derived testid is rendered at all. Both elements sit inside [data-testid="project-sidebar"].

(b) Why this is a suite fix and not a product finding

The project's name is still observable by every consumer that is not a test runner: it is the entry's text content, and it is the kebab's accessible name (aria-label="Options for <name>"). data-testid is an automation hook, not a product contract — nothing a user or a screen reader can perceive changed, so there is no user-facing defect to file.

Keying on the id is also the more correct choice under the change that introduced it: 23f91d8587 (fix(authz): support scoped project visibility, langflow-ai/langflow#14429) makes project visibility per-principal, and a project name is not unique across principals while its id is. The commit is on release-1.12.0 — the line the nightly is cut from — and not on main, which still renders sidebar-nav-${item.name}. That asymmetry is not a detail: manual.yml dispatches the @stable set against 1.11.x release candidates before every sign-off, so the suite has to satisfy both spellings, not migrate to one.

No REGRESSIONS.md row is owed, and no upstream ticket is filed.

(c) The entry is not gated away by authz — ruled out, not assumed

ProjectRenamePermission is a render-prop that always renders its child:

const ProjectRenamePermission = ({ projectId, children }) => {
  const { can } = usePermissions();
  return children(can(projectId, "write"));
};

canRename only guards onDoubleClick. Confirmed live: both projects on the instance render their entry. So the failure is the testid alone; nothing disappears behind a permission check.

(d) cleanOldFolders had indeed stopped deleting — second defect, confirmed

It hovered the entry and clicked more-options-button_<convertTestName(name)>, so from the moment upstream re-keyed the testid it deleted nothing and merely timed out on a click. That is the mechanism behind the New Project → New Project (5) accumulation the daily's retries recorded inside a single test.

It now sweeps through the REST API — this is teardown of the previous run and must not depend on the UI state the test it precedes is about to assert on, the same argument removeLeftoverRenamedProject already makes in the same file.

Measured on 1.12.0.dev20: 3 New Project* projects seeded through POST /api/v1/projects/, the spec run once, 0 of the 3 survived. Unit tests now pin the behaviour (deletes by id, reads both response shapes, does not abort on one undeletable leftover, does not sweep a name that merely contains "New Project").

Scope of the fix

Addressing lives in one place, tests/helpers/ui/project-sidebar.ts, matching both spellings as a single locator — they can never both match, since an entry carries exactly one testid and a project's name is never another project's uuid. The name branch carries its own deletion trigger (when 1.11.x leaves the support window).

Consumers updated: MainPage (deleteProject / clickProject / uploadFlowByDragDrop), createProjectThroughSidebar / renameProjectThroughSidebar, cleanOldFolders, the four quarantined specs, and the two latent ones (folder-drag-drop-flow, flow-navigation-between-folders).

One consequence worth recording: the rename assertion had to change observable. The id-derived testid does not change with a rename, so asserting on it would pass whether the rename committed or not — the entry's text is now what is asserted. Force-failed by making the helper skip the input fill: the three rename-dependent tests fail on toContainText, the two that do not rename still pass.

Out of scope, filed separately

#1376 — this file leaks one flow and one project per run, masked by the next run's cleanOldFolders. A cleanup defect, not an addressing one.