[MarcZX10]

What

The build_eligibility tests launched a fresh Node process for each scenario. Two Windows relinker CI runs timed out in this test while starting the nested harness: #5978 (two scenarios) and #6184 (one scenario). This PR keeps one Node harness process alive for the test class and sends each independent scenario as a JSON line. The cases and their assertions are unchanged, and each response retains the existing 20-second timeout.

Tested

Debian 12, Python 3.11.2, Node 20.19.2:

• python3 -m unittest tools.tests.test_build_eligibility passes 7/7 in 0.044 s.
• python3 tools/check_conventions.py --base upstream/main passes.
• git diff --check passes.

The Windows failures are recorded in #5978 and the #6184 relinker run. I have not run this change on Windows locally; its hosted Windows check will validate the behavior there.

Checklist

• Based on current main; no other open PR changes this test
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw; silent stubs are unaffected
• No notes, investigation files or images added
• No new third-party code
• Generic behavior, not specific to one title
• Depends on: fix(libkernel): share guest rename semantics with sceKernelRename #6484
• Unblocks: none
• GPUs tested: n/a
• AI-assisted: yes

[MarcZX10]

I traced the Windows build_eligibility failures in #6184 and #5978 to the nested Node process hitting the 20-second timeout; the other 176/177 tests pass. Your current head e192246 has green Ubuntu, macOS and Windows relinker checks, and its single-Node harness directly addresses that failure. Could you coordinate with those PR authors/maintainers on merging this shared test fix? Once it is on main, both affected PRs can rerun the Windows relinker job to verify the failures are cleared. I have not changed your branch or duplicated the fix.

[blawesom]

Rebase handoff — rebased onto current main (authorship unchanged). One conflict in tools/tests/test_build_eligibility.py: this PR replaces the per-scenario subprocess with a long-lived Node process (stdin/stdout line protocol), while main's side of the same region only carried the newer 90 s timeout on the old subprocess form — the PR's persistent-process design supersedes that region, so its side is taken (its own 20 s response timeout and kill-on-stall are kept).

Verified on Linux (CachyOS, kernel 7.2.9, GCC 16.2.1, Ninja, Release, BUILD_TESTING=ON, AMD RX 9070 XT / RADV):

• builds; the eligibility suite itself passes (7 tests, OK); tools/check_conventions.py --base origin/main passes
• full suite: 1286/1287 — the only failure is the known main regression (agc_driver_tessellation segfault, feat(shader): read hull inputs at a control-point index computed from data #4727), not this PR

To pick it up:

git fetch https://github.com/blawesom/AnyPS5 rebase/6583
git checkout <your branch>
git merge --ff-only FETCH_HEAD

Head is 0b416634d.

[MarcZX10]

Thanks for rebasing this onto current main and resolving the 90 s timeout overlap. I applied the handoff to the PR branch, preserving the MarcZX100 commit author and using MarcZX100 as committer. The focused suite passes 7/7, conventions pass, and diff check is clean on the rebased head ab2c6ee6e. The reported full-suite agc_driver_tessellation failure is recorded as the existing #4727 issue.

[Ondra97]

I propose merging #6484 first, then rebasing #6583. Both edit the harness completion and timeout handling: #6484 adds progress and timeout diagnostics, while #6583 replaces the per-scenario subprocess design. Its rebase can then adapt the useful failure diagnostics to the persistent harness. This order concerns the shared CI test file; the filesystem changes are independent.

If that order works for you, please declare Depends on: #6484 on #6583 until it lands.

AI-assisted: yes (Codex).

[MarcZX10]

Agreed on the ordering. I updated the checklist to Depends on: #6484; after #6484 lands, I will rebase this persistent-harness change and retain its failure diagnostics where they fit.

[MarcZX10]

Thanks, that merge order makes sense. #6484 is still open and currently conflicts with main, so I’ll wait for that rebase/merge before updating #6583; then I can adapt its subprocess changes to the merged completion and timeout handling.