morluto/rea

Fork 0

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

[GH-ISSUE #4392] [Bug] observe_web_session ends a window above 2^31-1 ms almost immediately but reports it as elapsed #1745

New issue

Closed

opened 2026-10-16 21:09:46 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

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

Owner

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

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

observe_web_session accepts any positive integer observation_ms. observeWebSessionInputSchema in src/domain/browserSession.ts has no maximum, and waitForWindow in src/browser/CdpObservationSession.ts passes the value directly to setTimeout. For a value above 2,147,483,647, Node sets the delay to 1 ms, so the window ends almost immediately. The result still reports end_reason: "window_elapsed" and requested_ms with the large value.

Reproduction

Call observe_web_session (or rea observe-web-session) with observation_ms set to 2147483648 against an allowed target.
Observe that the request returns after a few milliseconds with window.end_reason: "window_elapsed" and window.requested_ms: 2147483648.

I did not run this against a browser. I ran the timer behavior on its own: on Node 24.14.1, setTimeout(…, 2_147_483_648) printed TimeoutOverflowWarning: 2147483648 does not fit into a 32-bit signed integer. Timeout duration was set to 1. and fired after 7 ms. I also confirmed that observeWebSessionInputSchema.safeParse accepts observation_ms: 2147483648.

Expected behavior

observe_web_execution already bounds the same field with .max(2_147_483_647) in src/domain/webExecution.ts. observe_web_session should reject a value it cannot time, with an out_of_range issue that names the maximum, instead of reporting a window that did not happen.

Impact and scope

A caller who asks for a very long window gets a result that looks complete but covers about 1 ms. Values up to 2,147,483,647 (about 24.8 days) are not affected. Other observation tools that wait through delayWithCancellation split long delays and are not affected. #3392 (scenario timers overflow) is a related but separate report.

REA version

6.5.0, revision 8ab502439

Runtime and platform

Node 24.14.1 on Windows 11. Node's timer limit is the same on all platforms.

Target and artifact context

Browser observation over CDP. No target was used for the reproduction.

Interface

MCP

Earliest failure stage

Request parsing or validation

Relevant output or evidence

TimeoutOverflowWarning: 2147483648 does not fit into a 32-bit signed integer. Timeout duration was set to 1.

observeWebSessionInputSchema.safeParse({ cdp_endpoint: "http://127.0.0.1:9222", target_id: "target", observation_ms: 2147483648 }).success is true.

Typed outcome or recovery expected

invalid_request with the issue { "path": ["observation_ms"], "reason": "out_of_range", "maximum": 2147483647 }.

Analysis or suspected cause

Source-derived. The observation_ms field in observeWebSessionInputSchema lacks the .max(2_147_483_647) bound used by observeWebExecutionInputSchema, and waitForWindow uses one setTimeout for the whole window.

Additional context

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

Originally created by @Adolanium on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4392 ### 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 `observe_web_session` accepts any positive integer `observation_ms`. `observeWebSessionInputSchema` in `src/domain/browserSession.ts` has no maximum, and `waitForWindow` in `src/browser/CdpObservationSession.ts` passes the value directly to `setTimeout`. For a value above 2,147,483,647, Node sets the delay to 1 ms, so the window ends almost immediately. The result still reports `end_reason: "window_elapsed"` and `requested_ms` with the large value. ### Reproduction 1. Call `observe_web_session` (or `rea observe-web-session`) with `observation_ms` set to `2147483648` against an allowed target. 2. Observe that the request returns after a few milliseconds with `window.end_reason: "window_elapsed"` and `window.requested_ms: 2147483648`. I did not run this against a browser. I ran the timer behavior on its own: on Node 24.14.1, `setTimeout(…, 2_147_483_648)` printed `TimeoutOverflowWarning: 2147483648 does not fit into a 32-bit signed integer. Timeout duration was set to 1.` and fired after 7 ms. I also confirmed that `observeWebSessionInputSchema.safeParse` accepts `observation_ms: 2147483648`. ### Expected behavior `observe_web_execution` already bounds the same field with `.max(2_147_483_647)` in `src/domain/webExecution.ts`. `observe_web_session` should reject a value it cannot time, with an `out_of_range` issue that names the maximum, instead of reporting a window that did not happen. ### Impact and scope A caller who asks for a very long window gets a result that looks complete but covers about 1 ms. Values up to 2,147,483,647 (about 24.8 days) are not affected. Other observation tools that wait through `delayWithCancellation` split long delays and are not affected. #3392 (scenario timers overflow) is a related but separate report. ### REA version 6.5.0, revision `8ab502439` ### Runtime and platform Node 24.14.1 on Windows 11. Node's timer limit is the same on all platforms. ### Target and artifact context Browser observation over CDP. No target was used for the reproduction. ### Interface MCP ### Earliest failure stage Request parsing or validation ### Relevant output or evidence `TimeoutOverflowWarning: 2147483648 does not fit into a 32-bit signed integer. Timeout duration was set to 1.` `observeWebSessionInputSchema.safeParse({ cdp_endpoint: "http://127.0.0.1:9222", target_id: "target", observation_ms: 2147483648 }).success` is `true`. ### Typed outcome or recovery expected `invalid_request` with the issue `{ "path": ["observation_ms"], "reason": "out_of_range", "maximum": 2147483647 }`. ### Analysis or suspected cause Source-derived. The `observation_ms` field in `observeWebSessionInputSchema` lacks the `.max(2_147_483_647)` bound used by `observeWebExecutionInputSchema`, and `waitForWindow` uses one `setTimeout` for the whole window. ### Additional context Fix is in https://github.com/morluto/rea/pull/4391.

bsakaguchi commented

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

Author

Owner

@matbrgz commented on GitHub (Oct 16, 2026):

Cross-referencing with related numeric overflow defects #3400 ([Bug] Overflowing JavaScript timer delays abort application analysis) and #3861. In Node.js / V8, timeout durations exceeding signed 32-bit integer range (> 2^31 - 1 ms / 2,147,483,647 ms) truncate to 1 ms, firing almost immediately while reporting full window completion.

Indexed under Cluster S (JavaScript Timer Delay & Window Duration 32-bit Integer Overflow) in consolidation tracker #4330.

@matbrgz commented on GitHub (Oct 16, 2026): Cross-referencing with related numeric overflow defects #3400 (`[Bug] Overflowing JavaScript timer delays abort application analysis`) and #3861. In Node.js / V8, timeout durations exceeding signed 32-bit integer range (`> 2^31 - 1` ms / 2,147,483,647 ms) truncate to 1 ms, firing almost immediately while reporting full window completion. Indexed under **Cluster S (JavaScript Timer Delay & Window Duration 32-bit Integer Overflow)** in consolidation tracker #4330.

bsakaguchi referenced this issue

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

[GH-ISSUE #3796] [Tracker] Open feature requests by area (October 2026) #1471

bsakaguchi closed this issue

2026-10-31 00:32:31 +00:00

bsakaguchi commented

2026-10-31 00:32:32 +00:00

Author

Owner

@Adolanium commented on GitHub (Oct 21, 2026):

Closing as a duplicate of #3929, which reported the same overflow a day earlier and is fixed on main by #5605. I missed #3929 when searching before filing this.

@Adolanium commented on GitHub (Oct 21, 2026): Closing as a duplicate of #3929, which reported the same overflow a day earlier and is fixed on main by #5605. I missed #3929 when searching before filing this.

bsakaguchi referenced this issue

2026-10-31 00:41:06 +00:00

[GH-ISSUE #5744] [Feature] Analyze Thumb-only Cortex-M firmware in the raw-binary lane instead of refusing its entry point and decoding it as ARM state #3491

bsakaguchi referenced this issue

2026-10-31 00:56:42 +00:00

[PR #1922] feat(ghidra): verify and pin the 32-bit ARM (armhf) lane #4912