[GH-ISSUE #4388] [Bug] Electron scenario cancellation hangs on a windowless wait or a pending state read #1742

New issue

Closed

opened 2026-10-16 21:09:45 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-16 21:09:45 +00:00

Owner

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

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

capture_electron_scenario cannot be cancelled while a wait action without window_index waits for a first window that never opens, as with a tray or windowless app. The request keeps waiting after the abort signal fires, capture() never reaches its cleanup, and the owned Electron app keeps running.

The same happens when the initial state read does not settle, and when the request is cancelled while the final state read is pending.

Reproduction

Start capture_electron_scenario for an app that opens no BrowserWindow, with actions: [{ "step_id": "settle", "kind": "wait", "duration_ms": 10 }] and no window_index.
Cancel the request (CLI SIGINT or MCP cancellation).
Observe that the request does not return and the app is not closed.

I reproduced this only with stubbed Playwright objects: a firstWindow that never resolves, then an abort after 50 ms. The provider test timed out at 30 seconds. I did not run a real Electron app.

Expected behavior

docs/electron-observation.md says actions wait "until completion or request cancellation", and that CLI SIGINT/SIGTERM requests cancellation and awaits owned-process cleanup. Cancellation should stop the wait, return the typed cancelled error, and close and clean up the owned app.

Impact and scope

A cancelled capture can hang and leave the launched app running. This affects wait without window_index, the initial state read, and the final state read. Click, reload, crash, deep-link, and waitForWindow already observe the signal.

REA version

6.5.0, revision 8ab502439

Runtime and platform

Node 24 on Windows 11 for the stubbed reproduction. The code path is platform-independent.

Target and artifact context

Electron active capture. Stubbed ElectronApplication only.

Interface

MCP

Earliest failure stage

Cleanup, cancellation, or lifecycle

Relevant output or evidence

Error: Test timed out in 30000ms. for a capture with a firstWindow that never resolves and an abort after 50 ms.

Typed outcome or recovery expected

BrowserObservationError with reason cancelled, the wait step recorded with status: "cancelled", and the existing close and owned-process cleanup.

Analysis or suspected cause

Source-derived. runAction in src/browser/PlaywrightElectronActiveActions.ts awaits application.firstWindow({ timeout: 0 }) outside runWithExecutionLimits. In PlaywrightElectronActiveProvider.capture, the initial readApplicationState has no limits, and the final read passes undefined as the signal and sets a deadline only if the request was already aborted.

Additional context

Fix is in https://github.com/morluto/rea/pull/4387.

Originally created by @Adolanium on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4388 ### 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 `capture_electron_scenario` cannot be cancelled while a `wait` action without `window_index` waits for a first window that never opens, as with a tray or windowless app. The request keeps waiting after the abort signal fires, `capture()` never reaches its cleanup, and the owned Electron app keeps running. The same happens when the initial state read does not settle, and when the request is cancelled while the final state read is pending. ### Reproduction 1. Start `capture_electron_scenario` for an app that opens no `BrowserWindow`, with `actions: [{ "step_id": "settle", "kind": "wait", "duration_ms": 10 }]` and no `window_index`. 2. Cancel the request (CLI SIGINT or MCP cancellation). 3. Observe that the request does not return and the app is not closed. I reproduced this only with stubbed Playwright objects: a `firstWindow` that never resolves, then an abort after 50 ms. The provider test timed out at 30 seconds. I did not run a real Electron app. ### Expected behavior `docs/electron-observation.md` says actions wait "until completion or request cancellation", and that CLI SIGINT/SIGTERM requests cancellation and awaits owned-process cleanup. Cancellation should stop the wait, return the typed `cancelled` error, and close and clean up the owned app. ### Impact and scope A cancelled capture can hang and leave the launched app running. This affects `wait` without `window_index`, the initial state read, and the final state read. Click, reload, crash, deep-link, and `waitForWindow` already observe the signal. ### REA version 6.5.0, revision `8ab502439` ### Runtime and platform Node 24 on Windows 11 for the stubbed reproduction. The code path is platform-independent. ### Target and artifact context Electron active capture. Stubbed `ElectronApplication` only. ### Interface MCP ### Earliest failure stage Cleanup, cancellation, or lifecycle ### Relevant output or evidence `Error: Test timed out in 30000ms.` for a capture with a `firstWindow` that never resolves and an abort after 50 ms. ### Typed outcome or recovery expected `BrowserObservationError` with reason `cancelled`, the `wait` step recorded with `status: "cancelled"`, and the existing close and owned-process cleanup. ### Analysis or suspected cause Source-derived. `runAction` in `src/browser/PlaywrightElectronActiveActions.ts` awaits `application.firstWindow({ timeout: 0 })` outside `runWithExecutionLimits`. In `PlaywrightElectronActiveProvider.capture`, the initial `readApplicationState` has no limits, and the final read passes `undefined` as the signal and sets a deadline only if the request was already aborted. ### Additional context Fix is in https://github.com/morluto/rea/pull/4387.

bsakaguchi closed this issue

2026-10-16 21:09:45 +00:00

bsakaguchi referenced this issue

2026-10-17 21:01:32 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

2026-10-31 00:55:04 +00:00

[PR #1742] [MERGED] fix(browser): retain effective source-map response urls #4789