[CI][dev-up] 'Node helper: TERM closes an active frontend connection' reds ubuntu Frontend Unit on a docs-only PR: frontend helper did not bind within 5 s

[Chris0Jeky]

What

scripts/ci/dev-up.test.mjs case Node helper: TERM closes an active frontend connection (line ~1049) failed on the Linux Frontend Unit (ubuntu-latest) leg of a docs-only PR: AssertionError: frontend helper did not bind from waitUntil at line ~907 after 5034 ms; 43 passed, 1 failed.

• PR docs: record the fail-closed producer-triple projection and its columns (#2499 option a) #2586 (UPGRADING.md and DATA_MODEL.md only), CI run 33935622081, job 101222860762, 2026-09-05.
• The failed job was re-run once by the PR's author (the diff cannot reach the launcher suite); attempt one stays visible on the run.

Why it is its own record

This is not the Windows #2378 cohort (ETIMEDOUT / PowerShell cancellation shapes). The case was added by PR #2548 (#2135, close active dev-up stub connections on signal) and runs on Linux and macOS. The assertion that fired is the fixture helper's own bind wait (5 s), i.e. the stub frontend never reported a bound port on a hosted ubuntu runner, before the TERM behaviour under test was exercised. No open issue matched "did not bind" at the time of filing.

Ask

• Decide whether the 5 s bind wait in the fixture helper is too tight for a loaded hosted runner (the same runner-speed class as Frontend Unit (windows-latest) times out on slow runners: dev-up.test.mjs PowerShell spawns hit ETIMEDOUT and the job hits its timeout #2378 and [Backend][Testing] GetNotifications_WithManyNotifications_DoesNotTimeout asserts a 2 s wall-clock bound and reds Windows API Integration on slow runners #2489) or whether the helper can fail to bind for a reason worth fixing (port collision with a lingering fixture, see the orphaned-fixture evidence on Frontend Unit (windows-latest) times out on slow runners: dev-up.test.mjs PowerShell spawns hit ETIMEDOUT and the job hits its timeout #2378).
• Either raise the bind wait to the suite's standard ceiling and make the failure message name the port and the helper's stderr, or bind on port 0 and read the assigned port back if the fixture does not already.
• Any change lands under scripts/ci/** (control-plane, SC-10) and should ride with the next dev-up slice rather than alone.

Refs #2135, #2548, #2378, #1898.

[Chris0Jeky]

Occurrence (beta lane, 2026-09-05 08:49Z): PR #2671 at cf359fb (backend Cli plus docs, updated against main 1402132 minutes earlier; nothing under scripts/), run 33956288283, job 101280137772, Frontend Unit (ubuntu-latest): 'Node helper: TERM closes an active frontend connection' failed with 'AssertionError: frontend helper did not bind' after 5.0 s; 43 of 44 passed in 46.5 s. Same shape as this issue. It is the PR's second launcher-suite red in a row (the first, at afbd16b, was the Windows retained-state case recorded on #2561, answered by update-branch). Disposition: main has not moved since the update, so one rerun of the failed jobs; a third red parks the PR.