[PR #219] [CLOSED] fix(process): restrict cleanup to captured group leaders #1872

New issue

Closed

opened 2026-10-16 21:12:01 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-16 21:12:01 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/219
Author: @N0zoM1z0
Created: 7/14/2026
Status: ❌ Closed

Base: main ← Head: agent/process-cleanup

📝 Commits (1)

f762790 fix(process): restrict cleanup to captured group leaders

📊 Changes

4 files changed (+43 additions, -16 deletions)

View changed files

📝 src/application/ProcessCaptureLifecycle.ts (+2 -6)
📝 src/application/ProcessHarness.ts (+11 -10)
📝 src/application/ProcessOwnership.ts (+17 -0)
📝 tests/processOwnership.test.ts (+13 -0)

📄 Description

Summary

distinguish observed process membership from proof that REA captured a process-group leader
settle and clean only the PTY root plus groups whose captured leader was observed (pid === pgid)
retain the existing fail-closed REA_PROCESS_RUN_ID revalidation immediately before any signal
cover inherited unrelated PGIDs with a focused regression

On Linux, the forkpty parent can observe the new PTY process before child-side login_tty/setsid finishes. That transient sample legitimately reports the parent test runner’s PGID. The lifecycle previously promoted every sampled PGID into cleanup authority; the ownership layer then correctly rejected that unrelated group, turning a successful capture into a failure.

This fixes the authority derivation rather than weakening the ownership check.

Verification

35 process ownership/capture tests passed
exact fresh-process reproducer passed 21 consecutive iterations under load (unfixed failed at iteration 6)
npx tsc --noEmit
npm run lint (existing warnings only)
npm run format:check

This is the root-cause fix found while triaging #149; that broader timeout report remains open pending supported-runtime reproduction.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/219 **Author:** [@N0zoM1z0](https://github.com/N0zoM1z0) **Created:** 7/14/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `agent/process-cleanup` --- ### 📝 Commits (1) - [`f762790`](https://github.com/morluto/rea/commit/f762790e303118cdf2704d09df28449bec895b0e) fix(process): restrict cleanup to captured group leaders ### 📊 Changes **4 files changed** (+43 additions, -16 deletions) <details> <summary>View changed files</summary> 📝 `src/application/ProcessCaptureLifecycle.ts` (+2 -6) 📝 `src/application/ProcessHarness.ts` (+11 -10) 📝 `src/application/ProcessOwnership.ts` (+17 -0) 📝 `tests/processOwnership.test.ts` (+13 -0) </details> ### 📄 Description ## Summary - distinguish observed process membership from proof that REA captured a process-group leader - settle and clean only the PTY root plus groups whose captured leader was observed (`pid === pgid`) - retain the existing fail-closed `REA_PROCESS_RUN_ID` revalidation immediately before any signal - cover inherited unrelated PGIDs with a focused regression On Linux, the `forkpty` parent can observe the new PTY process before child-side `login_tty`/`setsid` finishes. That transient sample legitimately reports the parent test runner’s PGID. The lifecycle previously promoted every sampled PGID into cleanup authority; the ownership layer then correctly rejected that unrelated group, turning a successful capture into a failure. This fixes the authority derivation rather than weakening the ownership check. ## Verification - 35 process ownership/capture tests passed - exact fresh-process reproducer passed 21 consecutive iterations under load (unfixed failed at iteration 6) - `npx tsc --noEmit` - `npm run lint` (existing warnings only) - `npm run format:check` This is the root-cause fix found while triaging #149; that broader timeout report remains open pending supported-runtime reproduction. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-16 21:12:01 +00:00