Fix: read the orphan test's child pids from a file, not the parent's log

[ChaoWao]

main is currently red on ut because of this. My test from #1495, not the fix it guards.

What happened

test_orphan_child_reaping scraped the forked children's pids out of the parent subprocess's combined stdout+stderr, taking every digit-only token. That stream also carries log lines and warnings, so any bare number in them was read as a pid:

AssertionError: expected exactly 3 forked sub-worker pids, parent reported [6778, 6779, 6780, 3]
assert 4 == 3

The three real pids are correct — Worker._sub_pids is not at fault, and the run was otherwise healthy. The test failed for a parsing artifact.

Worse than a false failure: the finally block would then have sent SIGKILL to whatever process that stray number named.

Fix

Give the parent a dedicated pid file, named on its command line. stdout+stderr stay captured as a separate log, used only for diagnostics when an assertion fails.

Parsing a channel that carries nothing but the pids removes the class of failure rather than filtering harder against it — filtering harder is the same mistake in a different shape, and it is the third time this test has been bitten by how it identifies children:

attempt	how children were identified	what went wrong
#1495 v1	pgrep -P inside the parent	caught the shell os.popen spawns, and container pid 3
#1495 v2	Worker._sub_pids printed to stdout	correct source, but parsed out of a log stream
this	Worker._sub_pids written to its own file	—

The isdigit() filter goes too: a non-numeric token in a dedicated pid file would be a real defect worth surfacing, not noise to skip past.

Verification

• 15/15 consecutive local runs pass (the CI failure was intermittent, so a single run proves nothing).
• Red-to-green still holds against the pre-Fix: exit a forked worker child once its parent is gone #1495 worker.py: 3 of 3 children outlived their SIGKILLed parent by 20s — now exactly three pids, no phantom entry.
• pre-commit clean.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@ChaoWao, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 16 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: ae6c8045-6300-4b66-b77d-bbbb8ef8dcda

📥 Commits

Reviewing files that changed from the base of the PR and between 3dc617a and eaf6f66.

📒 Files selected for processing (1)

• tests/ut/py/test_worker/test_orphan_child_reaping.py

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[ChaoWao]

Correction to this PR's description, now that the sibling PRs' logs are readable: in CI this is deterministic, not intermittent.

Three independent runs, three different real pid sets, always the same trailing phantom:

#1501  parent reported [6778, 6779, 6780, 3]
#1502  parent reported [18101, 18102, 18104, 3]
#1503  parent reported [6515, 6516, 6517, 3]

Every ut job on every PR branched off current main fails this way. I described it as intermittent based on local runs (1 failure in ~22), but that was an artifact of this box's log output differing from CI's — some line the runner emits contains a bare 3, reliably.

So main's ut is red on both platforms for every PR until this lands, and the three PRs above are blocked on it rather than on anything of their own.