morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #120] Hopper owned shutdown can block or leave document cleanup incomplete #78

New issue

Closed

opened 2026-10-15 18:20:53 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:20:53 +00:00

Owner

Originally created by @morluto on GitHub (Jul 13, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/120

Bug Description

When REA owns the Hopper process lifetime on Linux, shutdown cannot safely use the same blocking document-close path as an externally managed Hopper session. The bridge may wait for background analysis inside Hopper, while process-group cleanup may fail before the session document has been closed. This can leave shutdown blocked or cleanup incomplete.

The owned-process path needs a bounded two-phase shutdown: request analysis cancellation, try verified process cleanup, and fall back to an explicit document shutdown before retrying cleanup when the process remains alive.

Steps to Reproduce

Start a Linux Hopper session through REA's owned demo-helper launch path.
Begin or retain active background analysis.
Close the REA session while the owned process group cannot be cleaned up on the first attempt.
Observe that the ordinary bridge shutdown path may wait inside Hopper, or that failed process cleanup has no document-close fallback before the final cleanup attempt.

Expected Behavior

Owned Linux shutdown does not block waiting for Hopper background analysis.
REA distinguishes a completed document shutdown from a response that requires launcher cleanup.
If the first verified process cleanup fails, REA explicitly stops analysis and closes the session document, then retries cleanup.
Externally managed Hopper sessions retain the ordinary stop-analysis-and-close-document behavior.
Cleanup remains bounded and reports an actionable warning if the owned process still cannot be cleaned up.

Actual Behavior

The bridge's ordinary shutdown path waits for background analysis and closes the document synchronously. That is appropriate when REA does not own Hopper, but can block the owned Linux path. Avoiding that wait alone is insufficient: if owned process cleanup fails, REA needs a fallback request that completes document shutdown before retrying cleanup.

Environment

REA version: current main
Node.js version: not version-specific
macOS version: not applicable
Hopper Disassembler version: Linux Hopper demo launch path
Target binary format: not format-specific

Additional Context

This issue is limited to Hopper process/document shutdown ownership. It does not change MCP task cancellation contracts or general permission policy.
Regression coverage should exercise both cleanup-required acknowledgements and the explicit document-shutdown fallback. Real Hopper behavior should be verified with the Linux verifier when available.

Originally created by @morluto on GitHub (Jul 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/120 ## Bug Description When REA owns the Hopper process lifetime on Linux, shutdown cannot safely use the same blocking document-close path as an externally managed Hopper session. The bridge may wait for background analysis inside Hopper, while process-group cleanup may fail before the session document has been closed. This can leave shutdown blocked or cleanup incomplete. The owned-process path needs a bounded two-phase shutdown: request analysis cancellation, try verified process cleanup, and fall back to an explicit document shutdown before retrying cleanup when the process remains alive. ## Steps to Reproduce 1. Start a Linux Hopper session through REA's owned demo-helper launch path. 2. Begin or retain active background analysis. 3. Close the REA session while the owned process group cannot be cleaned up on the first attempt. 4. Observe that the ordinary bridge shutdown path may wait inside Hopper, or that failed process cleanup has no document-close fallback before the final cleanup attempt. ## Expected Behavior - Owned Linux shutdown does not block waiting for Hopper background analysis. - REA distinguishes a completed document shutdown from a response that requires launcher cleanup. - If the first verified process cleanup fails, REA explicitly stops analysis and closes the session document, then retries cleanup. - Externally managed Hopper sessions retain the ordinary stop-analysis-and-close-document behavior. - Cleanup remains bounded and reports an actionable warning if the owned process still cannot be cleaned up. ## Actual Behavior The bridge's ordinary shutdown path waits for background analysis and closes the document synchronously. That is appropriate when REA does not own Hopper, but can block the owned Linux path. Avoiding that wait alone is insufficient: if owned process cleanup fails, REA needs a fallback request that completes document shutdown before retrying cleanup. ## Environment - REA version: current `main` - Node.js version: not version-specific - macOS version: not applicable - Hopper Disassembler version: Linux Hopper demo launch path - Target binary format: not format-specific ## Additional Context - This issue is limited to Hopper process/document shutdown ownership. It does not change MCP task cancellation contracts or general permission policy. - Regression coverage should exercise both cleanup-required acknowledgements and the explicit document-shutdown fallback. Real Hopper behavior should be verified with the Linux verifier when available.

bsakaguchi

2026-10-15 18:20:53 +00:00

closed this issue
added the
triage

bug
labels

bsakaguchi commented

2026-10-15 18:20:54 +00:00

Author

Owner

@morluto commented on GitHub (Jul 13, 2026):

Closing as already resolved by merged PR #116. This issue was opened from a stale local branch before checking the refreshed main state; no separate Hopper cleanup PR is needed.

@morluto commented on GitHub (Jul 13, 2026): Closing as already resolved by merged PR #116. This issue was opened from a stale local branch before checking the refreshed `main` state; no separate Hopper cleanup PR is needed.

bsakaguchi referenced this issue

2026-10-16 21:11:19 +00:00

[PR #78] [MERGED] Fix CLI analyze routing to enhanced workflow #1815

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#78

No description provided.

Rows
Columns