Skip to content

LE-2037 follow-up — migrate the two getElementById reads on node parameter fields to getByTestId #1101

Description

@Victor-w-Madeira

Context

Upstream langflow-ai/langflow#14312 (LE-2037 / langflow-ai/langflow#14096) makes node-parameter DOM ids unique by scoping them with the nodeId:

- id={id}
+ id={getNodeScopedDomId(id, nodeId)}
  data-testid={id}          // ← deliberately unchanged

data-testid keeps its unscoped, field-name-derived value, so every getByTestId(...) in this suite is unaffected. Only code that reads the DOM id breaks. Two specs do exactly that:

File Line Test Tags
tests/tests-automations/regression/core-components/api-request-component-regression.spec.ts 726 cURL mode parses command, auto-fills URL, executes GET and returns 200 @stable, @regression, @components
tests/tests-automations/regression/api/flows/api-component-regression.spec.ts 75 cURL mode POST with JSON body @release, @regression

Both call document.getElementById("popover-anchor-input-url_input") inside a page.waitForFunction. Once the fix reaches the image under test the lookup returns null, the predicate never satisfies, and the test dies on a bare Timeout exceeded with no attribution. The first one is @stable, so daily-stable.yml would open a daily-failure issue the first weekday after that.

This is version-agnostic — there is nothing to wait for

The replacement selector is already used successfully in both files on the current build: getByTestId("popover-anchor-input-url_input") appears at lines 15, 25, 116, 153, 181 of the API spec and at lines 345, 371, 414, 444, 473, 504, 535, 566+ of the component spec. The two getElementById calls are local inconsistencies inside files that already select the correct way. Since the fix leaves data-testid untouched, the testid form is correct before and after it.

Secondary benefit: expect(locator).toHaveValue() is an auto-retrying web-first assertion, so a failure reports the value actually seen instead of an unattributed timeout.

Baseline finding — the second spec is ALREADY red

Measured on nightly 1.12.0.dev9 with --retries=0:

  • core-components/api-request-component-regression.spec.tspasses.
  • api/flows/api-component-regression.spec.tsfails today, timing out on the very waitForFunction at line 73 (Timeout 20000ms exceeded).

A live DOM scout explains why, and it is not the DOM id: while the cURL tab is active the URL input is fully unmounted. Probing every element matching url_input:

  • cURL tab active → no url_input element exists at all (only textarea_str_curl_input).
  • after clicking tab_0_url → the input is back, already carrying the parsed value https://httpbin.org/post.

The sibling spec already handles this and documents it (api-request-component-regression.spec.ts:719-722"dev46 unmounts the URL-tab input while the cURL tab is active, so switch to the URL tab to observe the parsed value"). The API spec never switches tabs, so its wait can never satisfy on the current build.

Consequence for the scope: swapping getElementByIdgetByTestId alone would leave this spec red, because toHaveValue cannot resolve an unmounted element either. This spec also needs the missing tab_0_url click. That is a prerequisite of the migration, not a separate concern — the point of the change is to make the parsed-URL assertion observable and attributable.

Scope

  1. core-components/api-request-component-regression.spec.ts:724-733 — replace the waitForFunction with expect(getByTestId("popover-anchor-input-url_input")).toHaveValue(...).
  2. api/flows/api-component-regression.spec.ts:73-81 — same replacement, plus the missing tab_0_url click that makes the field observable.
  3. grep -rn "getElementById" tests/ must come back empty.

Validation

  • Both tests pass on the current (pre-fix) nightly — proving no version dependency.
  • Forced failure produces an attributed message (toHaveValue reports the actual value, not a bare timeout).
  • No 🚨 Backend Error: in the output.
  • npm run typecheck + npm run lint.

Process

Off-wave: there is no open milestone, so this is filed as an approved follow-up exception per CLAUDE.mdWhat to work on.

Metadata

Metadata

Labels

area:componentsConfiguração de componentesfollow-upApproved exception: follow-up of merged work (ROADMAP Intake)

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions