[Daily #1361] full-custom-component — code-button-modal never becomes visible after adding a custom component (recurrent 2×)

[Victor-w-Madeira]

Spun out of daily-failure triage #1361 (run 31163810520, 2026-08-07).

Upstream: not filed

Symptom

a full custom component built from code exposes its declared interface failed its first attempt waiting on the custom component's code-editor button, then passed on retry — a flake, recurrent under the same signature on 2026-08-05 and 2026-08-07.

Spec (line)	Waits for	Signature
tests/tests-automations/regression/core-components/full-custom-component.spec.ts:66 ("a full custom component built from code exposes its declared interface")	getByTestId('code-button-modal').last()	Error: expect(locator).toBeVisible() failed

Why these failures are one cause

Single test, single signature, matched by normalizeSignature() across both dailies — the dataset reports recurrence.same_signature: true over 2026-08-05 and 2026-08-07, which are non-adjacent. No grouping argument is being made beyond that.

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). The guard governs hard failures only and carries no exemption for the flake criterion, so this was quarantined exactly as it would have been on a clean day.

Descriptively: the wait is on code-button-modal becoming visible after a custom component is added to the canvas, and it recovered on the very next attempt both times — which is consistent with the node not having finished rendering when the assertion started, but equally with a genuine intermittent in the add-component path. Nothing here distinguishes the two yet. Both recorded occurrences fall on days the mass-failure guard tripped (2026-08-05: 24 hard failures; 2026-08-07: 8), which is a confound worth holding onto rather than a cause.

Investigation directive

Product first. (a) On the current nightly, add a custom component repeatedly with --retries=0 and measure how often the code button renders inside the 10 s budget — establish a rate before touching the spec. (b) If the button is genuinely late rather than absent, find a deterministic observable for "the custom component finished mounting" and wait on that instead of extending the timeout. (c) Rule out a load-dependent read: both occurrences are on saturated days, so reproduce once on a quiet instance and once under parallel load before concluding the spec is fragile.

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-08-05, 2026-08-07). 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-components/full-custom-component.spec.ts (test at line 66)

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

[Victor-w-Madeira]

Adjacent spec on the same path — and a barrier the passing sibling has that neither of these two does

Found while working #1363 on a local 1.12.0.dev20 instance. Recorded here because it sits on the add-a-custom-component path, not because it is the same failure — the difference is the useful part.

The observation

tests/tests-automations/regression/core-functionality/project-management/flowPage.spec.ts › save fails 3 of 3 runs on main, --workers=1 --retries=0, with no change of mine applied:

expect(locator).toHaveCount(expected) failed
  Locator: locator('.react-flow__node')
  Expected: 1
  Received: 0

It is @release only — no @stable — so the daily never runs it.

Why it is probably NOT this issue

	#1365 (full-custom-component:66)	flowPage › save
Node reaches the canvas	yes	no — .react-flow__node is 0
What times out	code-button-modal on a node that exists	the node itself never appears
Behaviour	flake — recovers on retry	deterministic, 3/3

So one fix should not be assumed to cover both. Folding this into #1365 would most likely close it while leaving flowPage red.

The lead, which does touch this issue

core-components/customComponentAdd.spec.ts exercises the same button and passes on the same instance and build (1/1). It differs from both failing specs by two barriers:

await page.getByTestId("blank-flow").click();
await expect(page.getByTestId("canvas_controls_dropdown")).toBeVisible({ timeout: 10000 });  // canvas mounted
await ensureCustomComponentButton(page);                                                     // Components section active
await page.getByTestId("sidebar-custom-component-button").click();

flowPage › save has neither — it goes straight from blank-flow to a bare waitForSelector on the button and clicks. Upstream, that button's handler is a silent no-op when its component is not resolved:

onClick={() => { if (customComponent) { addComponent(customComponent, "CustomComponent"); } }}

— so a click landing before the editor is ready produces exactly this: button visible, click accepted, nothing added, no error anywhere. ensureCustomComponentButton's own docblock already documents the sibling half of this (the sidebar mounting with a different section active, "a ~9% flake").

Only 6 specs use that helper. full-custom-component.spec.ts — this issue's spec — is not one of them, and it has no canvas-mounted barrier either. That does not explain a late code-button-modal on its own, but it is worth ruling out before (b): both recorded occurrences of this flake are on saturated days, and an unbarriered click is exactly what load turns into a race.

What this is not

I did not instrument the click, did not confirm the canvas-readiness hypothesis with a trace, and did not measure the rate under load — this is a lead, not a cause. flowPage › save looks like it warrants its own issue rather than a line in this one; flagging it here so the connection is on record either way.

Refs #1363, #966.