[GH-ISSUE #8562] [Bug] Recorded-crash verifier can release fixtures after cleanup failures #6651

Open
opened 2026-11-01 21:12:56 +00:00 by bsakaguchi · 0 comments
Owner

Originally created by @morluto on GitHub (Nov 1, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8562

Area

Recorded-crash real-provider verifier cleanup

Observed behavior

At revision 245a581818ab13694fa438a06e39898ce03ab206, the recorded-crash verifier attempts fixture root close after session and sentinel closes even if those close calls fail. It observes process lineage only after root close. Cleanup and lineage.

Separately, connectRecordedCrash awaits transport cleanup in its connection-failure handler before rethrowing the original connection failure. If cleanup also rejects, only the cleanup error is reported. Session acquisition.

Reproduction and evidence

On macOS arm64, Node 24.22.1, the actual verifier ran in a subprocess with simulated Linux platform and fake fixture/session/sentinel owners. Injected catalog, session-close and sentinel-close failures were all reported, but root close was still invoked. The fake root recorded invocation only; it did not prove directory deletion or surviving processes. A separate control called the actual session helper with distinct injected connection and transport-close errors: only the close error was returned and its cause was empty.

The SDK transport close completion caveat is described in #8555. No real GDB, strace, crash target or MCP server was run. Real-world frequency and impact are NOT_ENOUGH_INFO.

Expected behavior

Retain the private root while session or sentinel ownership remains unresolved; establish actual owned process completion before release. Preserve both connection and cleanup failures, and exercise partial acquisition, mixed outcomes and retry.

Originally created by @morluto on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8562 ### Area Recorded-crash real-provider verifier cleanup ### Observed behavior At revision `245a581818ab13694fa438a06e39898ce03ab206`, the recorded-crash verifier attempts fixture root close after session and sentinel closes even if those close calls fail. It observes process lineage only after root close. [Cleanup and lineage](https://github.com/morluto/rea/blob/245a581818ab13694fa438a06e39898ce03ab206/scripts/verify-recorded-crash.mjs#L341-L354). Separately, `connectRecordedCrash` awaits transport cleanup in its connection-failure handler before rethrowing the original connection failure. If cleanup also rejects, only the cleanup error is reported. [Session acquisition](https://github.com/morluto/rea/blob/245a581818ab13694fa438a06e39898ce03ab206/scripts/verify/recorded-crash/public.mjs#L15-L28). ### Reproduction and evidence On macOS arm64, Node 24.22.1, the actual verifier ran in a subprocess with simulated Linux platform and fake fixture/session/sentinel owners. Injected catalog, session-close and sentinel-close failures were all reported, but root close was still invoked. The fake root recorded invocation only; it did not prove directory deletion or surviving processes. A separate control called the actual session helper with distinct injected connection and transport-close errors: only the close error was returned and its cause was empty. The SDK transport close completion caveat is described in #8555. No real GDB, strace, crash target or MCP server was run. Real-world frequency and impact are NOT_ENOUGH_INFO. ### Expected behavior Retain the private root while session or sentinel ownership remains unresolved; establish actual owned process completion before release. Preserve both connection and cleanup failures, and exercise partial acquisition, mixed outcomes and retry.
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#6651
No description provided.