[GH-ISSUE #6374] [Bug] observe_web_session records subresource load failures as session events #3829

Closed
opened 2026-10-31 00:44:27 +00:00 by bsakaguchi · 0 comments
Owner

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

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 records every failed request in the observed tab as a session load_failed timeline event, including subresources such as blocked images and scripts, and iframe documents. The capture intends to keep only main-frame failures. TimelineCapture.#loadingFailed in src/browser/CdpObservationSession.ts skips a failure only when params.frameId names another frame, but CDP's Network.loadingFailed event has no frameId, so nothing is skipped.

Reproduction

Ran on Linux (WSL Ubuntu, Node 24.18.0) with the fake CDP browser used by tests/boundary/browser/cdpBrowserProvider.lifecycle_failures.test.ts:

  1. During the observation window, the page sends Network.requestWillBeSent for an image (type: "Image", frameId of the main frame), followed by Network.loadingFailed for that request with errorText: "net::ERR_BLOCKED_BY_CLIENT" and no frameId, as CDP sends it.
  2. Run observe_web_session / rea observe-web-session.
  3. On upstream/main, the returned timeline contains a load_failed event with net::ERR_BLOCKED_BY_CLIENT next to the real document failure.

Expected behavior

Only failures of main-frame document requests appear in the timeline, the same scope that redirects already use. Subresource and iframe failures are not recorded as session events.

Impact and scope

On real pages, ad blockers, broken images and failed analytics calls fill the session timeline with load_failed events that are not navigation failures. An agent can read them as the page failing to load.

REA version

6.7.0, revision 86655eac6

Runtime and platform

Linux (WSL Ubuntu), Node 24.18.0

Target and artifact context

No real site; fake CDP browser.

Interface

MCP

Earliest failure stage

Capture or observation

Relevant output or evidence

src/browser/CdpObservationSession.ts:

#loadingFailed(params: UnknownRecord, bufferedBeforeArm: boolean): void {
  const frame = cdpStringValue(params.frameId);
  if (frame !== undefined && frame !== this.mainFrameId) return;

CDP Network.loadingFailed parameters: requestId, timestamp, type, errorText, canceled, blockedReason, corsErrorStatus. There is no frameId. The frame is only available from the request's Network.requestWillBeSent.

Typed outcome or recovery expected

No new error. The timeline omits subresource failures.

Analysis or suspected cause

The failure filter reads a field the event does not have. The request's frame and type are known only from Network.requestWillBeSent, which #redirect already uses to scope redirects to the main-frame document.

Additional context

Fixed by #6373.

Originally created by @Adolanium on GitHub (Oct 22, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6374 ### 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` records every failed request in the observed tab as a session `load_failed` timeline event, including subresources such as blocked images and scripts, and iframe documents. The capture intends to keep only main-frame failures. `TimelineCapture.#loadingFailed` in `src/browser/CdpObservationSession.ts` skips a failure only when `params.frameId` names another frame, but CDP's `Network.loadingFailed` event has no `frameId`, so nothing is skipped. ### Reproduction Ran on Linux (WSL Ubuntu, Node 24.18.0) with the fake CDP browser used by `tests/boundary/browser/cdpBrowserProvider.lifecycle_failures.test.ts`: 1. During the observation window, the page sends `Network.requestWillBeSent` for an image (`type: "Image"`, `frameId` of the main frame), followed by `Network.loadingFailed` for that request with `errorText: "net::ERR_BLOCKED_BY_CLIENT"` and no `frameId`, as CDP sends it. 2. Run `observe_web_session` / `rea observe-web-session`. 3. On upstream/main, the returned `timeline` contains a `load_failed` event with `net::ERR_BLOCKED_BY_CLIENT` next to the real document failure. ### Expected behavior Only failures of main-frame document requests appear in the timeline, the same scope that redirects already use. Subresource and iframe failures are not recorded as session events. ### Impact and scope On real pages, ad blockers, broken images and failed analytics calls fill the session timeline with `load_failed` events that are not navigation failures. An agent can read them as the page failing to load. ### REA version 6.7.0, revision `86655eac6` ### Runtime and platform Linux (WSL Ubuntu), Node 24.18.0 ### Target and artifact context No real site; fake CDP browser. ### Interface MCP ### Earliest failure stage Capture or observation ### Relevant output or evidence `src/browser/CdpObservationSession.ts`: ```ts #loadingFailed(params: UnknownRecord, bufferedBeforeArm: boolean): void { const frame = cdpStringValue(params.frameId); if (frame !== undefined && frame !== this.mainFrameId) return; ``` CDP `Network.loadingFailed` parameters: `requestId`, `timestamp`, `type`, `errorText`, `canceled`, `blockedReason`, `corsErrorStatus`. There is no `frameId`. The frame is only available from the request's `Network.requestWillBeSent`. ### Typed outcome or recovery expected No new error. The timeline omits subresource failures. ### Analysis or suspected cause The failure filter reads a field the event does not have. The request's frame and type are known only from `Network.requestWillBeSent`, which `#redirect` already uses to scope redirects to the main-frame document. ### Additional context Fixed by #6373.
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#3829
No description provided.