[GH-ISSUE #8370] [Design] Expose active provider command cleanup in session status #6570

New issue

Open

opened 2026-11-01 21:12:19 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-01 21:12:19 +00:00

Owner

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

Before submitting

I searched the open and closed issues and pull requests for a related discussion.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This discussion does not include credentials, private samples, or sensitive target data.

Decision needed

Should binary_session expose unconfirmed cleanup owned by an active provider client's command, and if so should that extend cleanup_pending or be a separate scoped status? How should an agent discover a safe recovery before the client is retired?

Context and evidence

In the controlled production-adapter test described in #8369, a fake Kuna decompile-graph subprocess times out. An injected launcher performs normal process-group cleanup but deliberately reports the stop as unproven until released. The Kuna adapter retains its cleanup owner. In separate public MCP runs:

Direct procedure_callees returns a top-level cleanup_incomplete. Both get_call_graph and trace_call_path instead return success containing that child error (#8369).
Before closing, binary_session({detail:"summary"}) reports open:true and cleanup_pending:false in all three runs, while provider operation health reports the adapter unavailable.
The first close_binary reports cleanup_incomplete; status then reports open:false, cleanup_pending:true. Once the injected proof is released, a second close succeeds and the pending flag clears. Thus owner retention and retry work in this controlled case.

This uses an instrumented fake Kuna process, not a natural failure of a real release; it does not establish a leaked process. The field's present documentation describes retained resources whose cleanup has not succeeded, but it is unclear whether active-client child commands are intended to be included. An agent that loses the original error cannot infer a safe close retry solely from the observed pre-close flag. No autonomous agent trace was measured.

Expected interaction with targets

Read existing files, launch a caller-supplied analysis subprocess, and write owned temporary/cache data. The proposed status read does not itself execute or modify the target.

Boundary details

Status must use the existing resource owner's facts without starting work or assuming a PID is owned. Preserve the distinction between an active client with command cleanup pending, a retired client, and unrelated external-mutation owners; not every owner necessarily supports close_binary retry.

Options and tradeoffs

Compare extending the existing flag, introducing separately scoped active-command and retired-session cleanup fields, or explicitly narrowing the documented flag while exposing the active owner's state elsewhere. Recovery should only name an operation when that owner actually supports it. Avoid treating a successful provider operation or missing observation as proof of cleanup.

Verification available so far

I have a prototype or observed results

Success criteria and open questions

Exercise direct and composed calls, status before and after failed close, successful retry, and cases with more than one cleanup owner. Test real providers where a bounded controlled failure is possible; report untested hosts and natural-failure frequency. Check MCP full/compact status schemas and existing clients if the contract changes. No implementation has been proposed as settled.

References

Related #8369 (composed graph result) and #8353 (guidance after a client is retired). Tests used REA d54a4661, Node 24.22.1 and macOS arm64; three focused production-adapter/session tests passed with the injected subprocess/cleanup behavior.

cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Oct 31, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8370 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related discussion. - [x] I understand the contribution scope must be reviewed before integration; open questions are welcome here. - [x] This discussion does not include credentials, private samples, or sensitive target data. ### Decision needed Should `binary_session` expose unconfirmed cleanup owned by an **active provider client's command**, and if so should that extend `cleanup_pending` or be a separate scoped status? How should an agent discover a safe recovery before the client is retired? ### Context and evidence In the controlled production-adapter test described in #8369, a fake Kuna `decompile-graph` subprocess times out. An injected launcher performs normal process-group cleanup but deliberately reports the stop as unproven until released. The Kuna adapter retains its cleanup owner. In separate public MCP runs: - Direct `procedure_callees` returns a top-level `cleanup_incomplete`. Both `get_call_graph` and `trace_call_path` instead return success containing that child error (#8369). - Before closing, `binary_session({detail:"summary"})` reports `open:true` and `cleanup_pending:false` in all three runs, while provider operation health reports the adapter unavailable. - The first `close_binary` reports `cleanup_incomplete`; status then reports `open:false, cleanup_pending:true`. Once the injected proof is released, a second close succeeds and the pending flag clears. Thus owner retention and retry work in this controlled case. This uses an instrumented fake Kuna process, not a natural failure of a real release; it does not establish a leaked process. The field's present [documentation](https://github.com/morluto/rea/blob/d54a4661da20382ad8456564a08569fdd24131c5/docs/mcp-contracts.md#L852-L859) describes retained resources whose cleanup has not succeeded, but it is unclear whether active-client child commands are intended to be included. An agent that loses the original error cannot infer a safe close retry solely from the observed pre-close flag. No autonomous agent trace was measured. ### Expected interaction with targets Read existing files, launch a caller-supplied analysis subprocess, and write owned temporary/cache data. The proposed status read does not itself execute or modify the target. ### Boundary details Status must use the existing resource owner's facts without starting work or assuming a PID is owned. Preserve the distinction between an active client with command cleanup pending, a retired client, and unrelated external-mutation owners; not every owner necessarily supports `close_binary` retry. ### Options and tradeoffs Compare extending the existing flag, introducing separately scoped active-command and retired-session cleanup fields, or explicitly narrowing the documented flag while exposing the active owner's state elsewhere. Recovery should only name an operation when that owner actually supports it. Avoid treating a successful provider operation or missing observation as proof of cleanup. ### Verification available so far I have a prototype or observed results ### Success criteria and open questions Exercise direct and composed calls, status before and after failed close, successful retry, and cases with more than one cleanup owner. Test real providers where a bounded controlled failure is possible; report untested hosts and natural-failure frequency. Check MCP full/compact status schemas and existing clients if the contract changes. No implementation has been proposed as settled. ### References Related #8369 (composed graph result) and #8353 (guidance after a client is retired). Tests used REA `d54a4661`, Node 24.22.1 and macOS arm64; three focused production-adapter/session tests passed with the injected subprocess/cleanup behavior. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi added the

enhancement

triage

labels

2026-11-01 21:12:19 +00:00

bsakaguchi referenced this issue

2026-11-01 21:47:26 +00:00

[PR #6570] [MERGED] fix(tests): stabilize process fixtures and malformed input coverage #7379

bsakaguchi referenced this issue

2026-11-01 21:47:27 +00:00

[PR #6628] [CLOSED] fix(python): classify negative marshal string sizes as malformed #7383