[GH-ISSUE #7272] [Bug] capture-electron-scenario classifies an unresolved unrelated process as a token mismatch #4317

Closed
opened 2026-10-31 00:48:51 +00:00 by bsakaguchi · 0 comments
Owner

Originally created by @coygeek on GitHub (Oct 26, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/7272

Before submitting

  • I searched the open and closed issues for a related report.
  • I removed credentials, tokens, private paths, and sensitive target data.

Area

Process capture or runtime observation

Observed behavior

Controlled executions of the production Electron cleanup path returned process ownership token mismatch for PID(s): 200 for an unrelated process that had never acquired a retained identity. Its evidence still said identity-unresolved. A first final sweep encountered unavailable identity information; a subsequent sweep recovered a stable unrelated identity and a different synthetic run marker. That readable marker caused an ownership-conflict error instead of preserving the unresolved earlier identity. Both matching verified lineage and unavailable lineage reproduced the failure. Only the owned group was signaled, and the unrelated process was never signaled.

These are observed production-boundary fixtures. A real CLI Electron capture and a native Linux race were not executed; their reachability was checked from source.

Reproduction

  1. Execute a focused Vitest fixture with one persistent process-evidence owner, owned leader/group 100, and unrelated PID/group 200 with parent 1. Supply an empty capture baseline, representing a candidate that appeared after baseline collection.
  2. In the first verification sweep, supply unavailable native identity and unavailable environment observations for PID 200. In the next two sweeps, supply a stable readable identity, native parent 1/group 200, and a readable synthetic marker different from the capture's marker.
  3. The first result is process-identity-unavailable; the next two results are run-token-mismatch, with the retained identity still undefined. With a fresh owner and the same recovered unrelated process, verification succeeds. A genuinely related foreign-marker control fails correctly.
  4. Exercise the production Electron cleanup entry with a valid leader and readable tokens during planning. After its owned-group signal, make PID 200's identity unavailable for the first final sweep, then readable on later sweeps while its marker remains different. Both matching verified and unavailable lineage variants reach the same mismatch through the built-in final-verification retry loop. The fixture signals group 100 exactly once.

The sweep scenario reproduced in both initial focused runs; the expanded run also passed both cleanup-entry variants, for three tests in one file. A subsequent run of the report's standalone sweep fixture passed as well. The fixtures created or signaled no real target processes. All process facts and markers were synthetic.

Expected behavior

AGENTS.md, Architecture and Cleanup, requires unresolved identity or applicability to remain unknown rather than be classified as foreign, absent, or aligned. A later readable unrelated generation does not identify the earlier unresolved generation. Preserve that uncertainty rather than assert a token ownership conflict from retention alone. Related generations with established scope and a different marker must continue to fail; this report does not require unconditional successful cleanup or dropping unresolved evidence.

Impact and scope

P2: a bounded conservative cleanup failure with a persistent incorrect ownership-conflict diagnosis. The fixture failure survives the final-verification retry window and can become a capture cleanup error. Native occurrence frequency and real-provider incidence are unknown. No severe harm, data loss, or unauthorized signaling was established. A supported caller workaround was not verified; fresh-owner success is a diagnostic control, not a recommended recovery operation.

REA version

615fbbbdd7 (package.json version 6.8.0)

Runtime and platform

Node v26.12.1, macOS arm64, Vitest 5.0.3. The fixture used Linux-style process observations. No Hopper, Ghidra, IDA, Electron executable, or device was used.

Target and artifact context

Synthetic owned leader and unrelated process rows; no target binary or analysis artifact.

Interface

CLI

Earliest failure stage

Cleanup, cancellation, or lifecycle

Relevant output or evidence

Observed fixture results:

First sweep: cleaned=false; process-identity-unavailable
Second sweep: cleaned=false; run-token-mismatch; PID=200
Third sweep: cleaned=false; run-token-mismatch; PID=200
Retained candidate: identity=undefined; applicability=identity-unresolved
Fresh-owner unrelated control: cleaned=true; signaled=false
Related foreign-marker control: cleaned=false; run-token-mismatch
Electron cleanup, both lineage variants: cleaned=false; run-token-mismatch
Groups signaled by fixture: [100], once

Source-derived failure: src/process/ProcessOwnershipEvidence.ts:288 retains an identity-less entry after a readable nonmatching marker. src/process/ProcessOwnership.ts:1677 then classifies any retained candidate with a current stable nonmatching marker as run-token-mismatch, including this unresolved entry.

Source-derived public reachability: src/cli/electronCommands.ts:106 accepts valid capture JSON and calls the default provider after local path admission. src/browser/PlaywrightElectronActiveProvider.ts:119 prepares inspection, admits inspect-capable Electron, collects the prelaunch baseline, checks the launched PID, and enables token sweeps with a persistent evidence owner. Cleanup with matching verified or unavailable lineage calls POSIX group cleanup. src/process/ProcessOwnership.ts:425 retries its final sweep with that same owner. The concrete trigger places the transient failure after the valid planning/signal stage, so earlier cleanup-plan guards do not block it. An unrelated post-baseline PID is admitted; retained PIDs are always reread. This provider path uses the group cleanup retry loop rather than the separate family-release helper.

Native producer: src/process/ProcessOwnershipObservation.ts:1150 can return an unavailable Linux identity when proc-stat disappears but a later signal-zero presence probe succeeds. PID exit/reuse between those observations can produce this input; later stat/environment reads can recover. This is source-derived, not a reproduced native race. In the cleanup-entry tests, the environment remained readable throughout, demonstrating that unavailable identity alone is sufficient.

Typed outcome or recovery expected

Report unresolved identity or applicability until sufficient evidence establishes the candidate's relationship to the run. Do not derive an ownership-conflict diagnosis solely from an identity-unresolved retained entry. Keep positive ownership requirements for all signaling.

Additional context

Open issue #4322 concerns an exiting formerly owned process; this fixture has a live unrelated generation whose earlier identity was never known. Open issue #7143 concerns unreadable environment access, while the erroneous mismatch here occurs after successful marker reads. Closed issue #5238 concerns stale UID evidence permitting completion, and closed issue #6204 concerns Linux environment-withholding policy. The inspected reports do not describe this specific retained unknown-identity transition.

Originally created by @coygeek on GitHub (Oct 26, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7272 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Process capture or runtime observation ### Observed behavior Controlled executions of the production Electron cleanup path returned `process ownership token mismatch for PID(s): 200` for an unrelated process that had never acquired a retained identity. Its evidence still said `identity-unresolved`. A first final sweep encountered unavailable identity information; a subsequent sweep recovered a stable unrelated identity and a different synthetic run marker. That readable marker caused an ownership-conflict error instead of preserving the unresolved earlier identity. Both matching verified lineage and unavailable lineage reproduced the failure. Only the owned group was signaled, and the unrelated process was never signaled. These are observed production-boundary fixtures. A real CLI Electron capture and a native Linux race were not executed; their reachability was checked from source. ### Reproduction 1. Execute a focused Vitest fixture with one persistent process-evidence owner, owned leader/group 100, and unrelated PID/group 200 with parent 1. Supply an empty capture baseline, representing a candidate that appeared after baseline collection. 2. In the first verification sweep, supply unavailable native identity and unavailable environment observations for PID 200. In the next two sweeps, supply a stable readable identity, native parent 1/group 200, and a readable synthetic marker different from the capture's marker. 3. The first result is `process-identity-unavailable`; the next two results are `run-token-mismatch`, with the retained identity still undefined. With a fresh owner and the same recovered unrelated process, verification succeeds. A genuinely related foreign-marker control fails correctly. 4. Exercise the production Electron cleanup entry with a valid leader and readable tokens during planning. After its owned-group signal, make PID 200's identity unavailable for the first final sweep, then readable on later sweeps while its marker remains different. Both matching verified and unavailable lineage variants reach the same mismatch through the built-in final-verification retry loop. The fixture signals group 100 exactly once. The sweep scenario reproduced in both initial focused runs; the expanded run also passed both cleanup-entry variants, for three tests in one file. A subsequent run of the report's standalone sweep fixture passed as well. The fixtures created or signaled no real target processes. All process facts and markers were synthetic. ### Expected behavior `AGENTS.md`, Architecture and Cleanup, requires unresolved identity or applicability to remain unknown rather than be classified as foreign, absent, or aligned. A later readable unrelated generation does not identify the earlier unresolved generation. Preserve that uncertainty rather than assert a token ownership conflict from retention alone. Related generations with established scope and a different marker must continue to fail; this report does not require unconditional successful cleanup or dropping unresolved evidence. ### Impact and scope P2: a bounded conservative cleanup failure with a persistent incorrect ownership-conflict diagnosis. The fixture failure survives the final-verification retry window and can become a capture cleanup error. Native occurrence frequency and real-provider incidence are unknown. No severe harm, data loss, or unauthorized signaling was established. A supported caller workaround was not verified; fresh-owner success is a diagnostic control, not a recommended recovery operation. ### REA version 615fbbbdd750de2df5d92b9827d0c7c4422c1d03 (package.json version 6.8.0) ### Runtime and platform Node v26.12.1, macOS arm64, Vitest 5.0.3. The fixture used Linux-style process observations. No Hopper, Ghidra, IDA, Electron executable, or device was used. ### Target and artifact context Synthetic owned leader and unrelated process rows; no target binary or analysis artifact. ### Interface CLI ### Earliest failure stage Cleanup, cancellation, or lifecycle ### Relevant output or evidence Observed fixture results: ```text First sweep: cleaned=false; process-identity-unavailable Second sweep: cleaned=false; run-token-mismatch; PID=200 Third sweep: cleaned=false; run-token-mismatch; PID=200 Retained candidate: identity=undefined; applicability=identity-unresolved Fresh-owner unrelated control: cleaned=true; signaled=false Related foreign-marker control: cleaned=false; run-token-mismatch Electron cleanup, both lineage variants: cleaned=false; run-token-mismatch Groups signaled by fixture: [100], once ``` Source-derived failure: `src/process/ProcessOwnershipEvidence.ts:288` retains an identity-less entry after a readable nonmatching marker. `src/process/ProcessOwnership.ts:1677` then classifies any retained candidate with a current stable nonmatching marker as `run-token-mismatch`, including this unresolved entry. Source-derived public reachability: `src/cli/electronCommands.ts:106` accepts valid capture JSON and calls the default provider after local path admission. `src/browser/PlaywrightElectronActiveProvider.ts:119` prepares inspection, admits inspect-capable Electron, collects the prelaunch baseline, checks the launched PID, and enables token sweeps with a persistent evidence owner. Cleanup with matching verified or unavailable lineage calls POSIX group cleanup. `src/process/ProcessOwnership.ts:425` retries its final sweep with that same owner. The concrete trigger places the transient failure after the valid planning/signal stage, so earlier cleanup-plan guards do not block it. An unrelated post-baseline PID is admitted; retained PIDs are always reread. This provider path uses the group cleanup retry loop rather than the separate family-release helper. Native producer: `src/process/ProcessOwnershipObservation.ts:1150` can return an unavailable Linux identity when proc-stat disappears but a later signal-zero presence probe succeeds. PID exit/reuse between those observations can produce this input; later stat/environment reads can recover. This is source-derived, not a reproduced native race. In the cleanup-entry tests, the environment remained readable throughout, demonstrating that unavailable identity alone is sufficient. ### Typed outcome or recovery expected Report unresolved identity or applicability until sufficient evidence establishes the candidate's relationship to the run. Do not derive an ownership-conflict diagnosis solely from an identity-unresolved retained entry. Keep positive ownership requirements for all signaling. ### Additional context Open [issue #4322](https://github.com/morluto/rea/issues/4322) concerns an exiting formerly owned process; this fixture has a live unrelated generation whose earlier identity was never known. Open [issue #7143](https://github.com/morluto/rea/issues/7143) concerns unreadable environment access, while the erroneous mismatch here occurs after successful marker reads. Closed [issue #5238](https://github.com/morluto/rea/issues/5238) concerns stale UID evidence permitting completion, and closed [issue #6204](https://github.com/morluto/rea/issues/6204) concerns Linux environment-withholding policy. The inspected reports do not describe this specific retained unknown-identity transition.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#4317
No description provided.