test(core-components): promote duplicate-dom-ids-regression to @stable (#1109)

[Victor-w-Madeira]

Closes #1109.

core-components/duplicate-dom-ids-regression.spec.ts was merged without @stable
deliberately (#1102 / PR #1106): the upstream fix it asserts — langflow#14312 (LE-2037 /
langflow-ai/langflow#14096) — existed only on the release-1.11.2 branch, while
langflowai/langflow-nightly:latest is built from the highest release-* branch. Both
cases hard-failed on the nightly by design, and tagging them then would have opened a
daily-failure issue every weekday and tripped auto-remove-stable into stripping the tag
and committing to main.

With nightly.yml disabled, that left the spec running nowhere except a PR's
impacted-specs job — and not reliably even there: @agents makes
scripts/provider-dependent-specs.mjs classify it provider-dependent, so a PR that
merely changed a helper it imports would have excluded it. #1109 was the tracker for
the other half of that decision.

The trigger fired — on the ref that decides it

Not main. The nightly is cut from the release line, so the check that matters is
release-1.12.0, and the helper now resolves on both at the same sha:

$ gh api .../get-node-scoped-dom-id.ts?ref=main            --jq .sha  → a8a903e
$ gh api .../get-node-scoped-dom-id.ts?ref=release-1.11.2  --jq .sha  → a8a903e
$ gh api .../get-node-scoped-dom-id.ts?ref=release-1.12.0  --jq .sha  → a8a903e

1. Promoted tests

#	Test	What it validates
1	two API Request nodes expose the same field without duplicating its DOM id	On a two-node canvas, popover-anchor-input-url_input resolves to exactly 2 elements (the data-testid stays unscoped — the contract 132 call sites across 45 specs depend on), both carry a non-empty DOM id, the two ids differ, and the canvas-scoped input/textarea/select sweep returns []
2	two Agent nodes expose the same field without duplicating its DOM id	The same contract on textarea_str_system_prompt across two dragged Agent nodes. The Agent is placed and inspected, never executed — no LLM call, no credential

2. Green for the right reason, not merely green

The issue's acceptance criterion was that the ids read …-APIRequest-<suffix> /
…-Agent-<suffix>, not just that the assertions pass. Captured from the force-fail runs,
which print the real values:

popover-anchor-input-url_input-APIRequest-P55sP  /  …-APIRequest-c5ewx
textarea_str_system_prompt-Agent-k1lgI           /  …-Agent-mBubM

popover-anchor-input-input_value on the Agent — a pre-fix duplicate recorded in the spec
doc's measurement table — is scoped as well. The field testid still resolved to 2
elements in both cases, so the contract half stayed green across the fix.

3. Force-failability audit

A promotion is where a spec that cannot fail becomes a blind spot in the daily, so the file
was read for dead assertions, if (visible) bodies and silent early-return chains before
trusting the green. It has none — every assertion is unconditional and
collectDuplicateFormFieldIds throws when the canvas root is missing rather than returning
an empty list. Nothing needed hardening; the mutations below prove all three assertions are
live, per test, isolated with --grep.

4. Scope, and the one logic change

The promotion itself is tag + doc + checklist bullet. An independent review of that commit
found two races, both fixed here. Neither can cause a wrong verdict — both fail hard
and are never a vacuous pass — but on the daily a hard failure strips @stable
automatically and commits to main, so they are worth closing before promotion rather than
triaging after it.

1. The field read did not wait. expectFieldIdsUniquePerNode read the ids through
   evaluateAll, which resolves the selector once, with no auto-wait. The only prior
   gate was .react-flow__node reaching 2 — that proves the nodes mounted, not their
   parameter fields, so a field arriving one commit later read as got 0. Now gated on the
   field testid reaching 2 first. Force-failed at toHaveCount(3) on both cases.
2. Case B did not check between its two drags. Case A gates on the first node rendering
   before adding the second, and says why in its own comment; Case B fired both dragTo
   calls back to back and let the final toHaveCount(2) catch whatever went missing — 15 s
   later, without naming which drag was lost. [Daily #1296] modelInputComponent — the canvas renders no node at all, so the model-name trigger is never reachable (hard failure, no outage cover) #1304 measured 4/20 swallowed sidebar
   interactions on this nightly line, so the path is live. The loop now asserts the running
   count after each drop. Force-failed at index + 2: "Agent drag 1/2 did not land on the
   canvas — Expected 2, Received 1".

The same review found five defects introduced by the promotion's own doc edit — a
truncated opening sentence in Tags, a measurement row left unanchored when the bullet
naming its build was rewritten away, literal DOM ids recorded as if a per-node nonce were a
contract, a circular duplicate claim between Tags and Preconditions, and an @agents
note that understated the tooling. All repaired in the same commit.

5. @agents — the tag is a subject, the tooling reads it as a dependency

Not changed here, but it has two live consequences and the PR should name both.
scripts/provider-dependent-specs.mjs treats @agents as a provider declaration,
file-scoped, so it marks both cases even though neither executes the Agent:

• A PR that changes this spec — like this one — forces the Collect models sweep,
  which is a hard gate on pr-validation.yml. Confirmed on this PR's own run: Collect models executed for 1.3 min with all five keys. So a tag-and-doc PR is coupled to
  provider-key health; the day a key drains (OpenAI API key out of quota — OpenAI-bound @stable specs hard-fail every daily #772 / Provider-hardcoded specs gate on the env var, not on provider health — a drained key wedges the shard #1029 / pr-validation: the lane pays for multi-provider LLM coverage it does not owe (141 runs / 3.5 days on claude-sonnet-5) #1169) it goes red for a reason
  unrelated to its diff.
• A PR that only changes a helper this spec imports gets it excluded and announced.

Neither is a bug in that mechanism; both rest on a premise this file does not meet. The
spec doc now records it. Changing the classifier or the tag is a separate question and is
not smuggled into a promotion.

Validation (nightly 1.12.0.dev18, --retries=0 --workers=1)

• Bursts — before the review fixes: 7.7 s / 7.7 s / 7.3 s, plus 7.5 s after the tag
  edit. After the first: 7.9 s / 6.7 s / 6.6 s. After the second: 7.3 s / 7.0 s / 6.9 s.
  2 passed every time, 10 runs in total ✅
• CI, independently: the impacted-specs lane ran this spec on 1.12.0.dev18 after
  Collect models — 2 passed (10.4 s) ✅
• --trace=on ✅ — 8.4 s, no hang (this spec places nodes, it does not load the Simple
  Agent template whose canvas hangs tracing)
• Zero 🚨 Backend Error on every run ✅
• Force-fail, executed, one mutation per assertion and isolated per test:
  • new Set(ids).size → .toBe(3) → 1 failed in both tests, printing the real
    node-scoped ids
  • duplicate sweep count > 1 → count > 0 → 1 failed in both (Case A named both
    url_input ids; Case B all four)
  • testid stability toHaveLength(2) → toHaveLength(3) → 1 failed in both
  • the new field-mount gate toHaveCount(2) → toHaveCount(3) → 1 failed in both
  • the new inter-drag gate toHaveCount(index + 1) → toHaveCount(index + 2) → 1 failed,
    naming the drag
  • reverted each time: grep FFMUT = 0, and the spec diff was empty before the tag edit ✅
• Flow cleanup verified — 26 flows on the instance, all starter projects, zero orphans
  after 6 executions ✅
• npm run typecheck ✅ · npm run lint 0 errors ✅ · QA-CHECKLIST generated-block guard ✅ ·
  check:checklist-coverage ✅ · --grep @stable now selects both tests ✅
• QA-CHECKLIST.md: the manual §2.1 bullet only ([-] → [x]). coverage:summary was not
  run and no generated block is committed (Guard QA-CHECKLIST generated blocks from PR edits (stop recurring merge conflicts) #741).

[Copilot]

🟢 Ready to approve

Only minor doc wording cleanup is suggested; the functional change is limited to adding @stable tags and aligning the checklist/doc accordingly.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Pull request overview

This PR promotes the existing duplicate DOM-id regression coverage for node parameter fields to @stable, ensuring it runs in the weekday daily-stable.yml lane now that the upstream fix is present in the nightly release line.

Changes:

• Add @stable to both tests in core-components/duplicate-dom-ids-regression.spec.ts.
• Update the corresponding QA checklist bullet from [-] to [x].
• Refresh the spec doc to reflect the promotion, updated validation baseline (1.12.x), and the release-line rationale.

File summaries

File	Description
tests/tests-automations/regression/core-components/duplicate-dom-ids-regression.spec.ts	Adds @stable tags to both regression tests.
QA-CHECKLIST.md	Updates the manual Part II bullet to mark the coverage as validated ([x]).
docs/core-components/duplicate-dom-ids-regression.md	Updates tags/validation context and documents why/when @stable was added.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 1
• Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.