✨ forward logs from the renderer process

[kikoveiga]

Motivation

The Electron bridge already receives log events from the renderer Browser Logs SDK, but RendererPipeline discarded them. In bridge mode the Browser SDK sends logs only to the host, so installing the Electron SDK alongside @datadog/browser-logs could silently lose every renderer log.

Ticket: RUM-15536

Changes

Forward and enrich renderer logs

• Forward valid Browser Logs payloads as ServerLogsEvent objects on a dedicated LOGS track.
• Preserve renderer-owned fields such as date, message, status, service, ddtags, view, and action context.
• Add Electron application and session ids, and fill user/account context only when the renderer did not provide it.
• Keep forwarding logs that have no covering RUM session, with the Browser SDK stub session ids removed.
• Upload with ddsource=browser while retaining DD-EVP-ORIGIN: electron for the uploader identity.

Sample logs in the host SDK

Browser Logs uses an always-tracked session stub in bridge mode, so renderer DD_LOGS.init({ sessionSampleRate }) does not sample logs sent over the bridge. This adds logsSampleRate to Electron SDK configuration:

• accepts 0–100 and defaults to 100;
• samples each valid renderer log independently before enrichment;
• stays independent from RUM sessionSampleRate;
• matches the Android and iOS WebView integrations;
• does not impose a separate relay cap on sampled-in logs.

Close reliability and API gaps

• Initialize all transport handlers before opening the renderer IPC listener, preventing startup-time event loss.
• Rotate LOGS batches at 1,000 entries as well as the shared byte limit, respecting the Logs intake array limit without dropping events.
• Handle null renderer user/account context safely.
• Reuse the common renderer emission path for RUM, telemetry, and logs.
• Align public nested log types with Browser Logs payloads and export LogsAssembleParams from the assembly barrel.
• Document renderer-log setup and sampling in README.md, and keep the architecture overview concise.

Verification

yarn typecheck
yarn test:unit
yarn test:e2e:init
yarn playwright test -c e2e --project=e2e e2e/scenarios/logs.scenario.ts

• 56 unit-test files / 1,061 tests passed.
• All 5 renderer Logs E2E scenarios passed, including logsSampleRate: 0 and a 1,001-log upload split into requests of 1,000 and 1.
• ESLint, Prettier, and git diff --check passed for the changed files.

Checklist

• Added unit tests.
• Added end-to-end coverage.
• Updated public and architecture documentation.
• Addressed or documented the agentic review findings.

[cursor]

PR Review — Score: 4.8 / 5

This is a well-executed feature PR that closes an important gap: once the Browser Logs SDK is in bridge mode, renderer logs have no other path to Datadog, and this change makes relay reliable end-to-end. The implementation follows established SDK patterns (format hooks, customer-context precedence, mobile WebView parity for logsSampleRate), fixes the init-order race by registering transport before opening the IPC listener, and is backed by thorough unit and e2e coverage including the 1,000-entry intake split. I would approve.

Why 4.8: Correct boundary validation, observable failures via telemetry, monitor() on the IPC path, intentional context-merging rules, unconditional LOGS track registration for recovery, batch rotation at the intake limit, and documentation/README updates that explain the bridge-mode sampling contract clearly.

Why not 5: The top-level monitoring architecture diagram still depicts only RUM over the bridge (logs get a prose section but not a diagram edge), and configuration telemetry has no schema field for logsSampleRate yet so usage of non-default sampling is invisible in SDK configuration events (consistent with existing telemetry constraints, but still a small observability gap).

---

Findings

• [Nit] Architecture diagram omits logs — The new Logs section is accurate, but the overview Mermaid chart still labels the bridge as RUM-only; a second edge (or relabel) would match the new behavior.

---

Architectural flow

sequenceDiagram
    participant BL as Browser Logs SDK
    participant Bridge as DatadogEventBridge
    participant RP as RendererPipeline
    participant Hooks as Format Hooks
    participant EM as EventManager
    participant T as Transport LOGS track
    participant Intake as Datadog Logs Intake

    BL->>Bridge: assembled log event
    Bridge->>RP: IPC log message
    RP->>RP: validate date message status
    RP->>RP: apply logsSampleRate
    RP->>Hooks: triggerLogs enrichment
    Hooks-->>RP: application session usr account
    RP->>EM: ServerLogsEvent on LOGS track
    EM->>T: post to batch producer
    T->>Intake: POST /api/v2/logs with ddsource=browser

Loading

Before: Bridge log events were accepted over IPC but dropped in RendererPipeline (TODO), so renderer logs in bridge mode were lost after the Browser Logs SDK stopped talking to intake directly.

After: Valid logs are sampled via logsSampleRate, enriched with main-process session/application/user/account context while preserving renderer-owned fields (service, ddtags, view, etc.), batched on a dedicated LOGS track (splitting at 1,000 events), and uploaded with ddsource=browser and DD-EVP-ORIGIN: electron. Transport handlers are registered before the IPC listener opens so events cannot fall through an unhandled gap during init().

  

_{Sent by Cursor Automation: electron-sdk reviews}

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-07T09:36:47.370554Z	1296494	New commits

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1296494983

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Add an example for the exported LogsEvent API

The new LogsEvent type is exported from src/index.ts, making it a public API, but its JSDoc has no @example. docs/REVIEW.md explicitly requires every new or modified public API to include one; add a representative Browser Logs payload example so the generated declarations meet the repository's API documentation standard.

AGENTS.md reference: AGENTS.md:L3-L6

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Document the renderer-side Logs SDK initialization

When a customer follows this new section, it only shows configuring the main-process Electron SDK and never tells them to install and initialize @datadog/browser-logs. The preceding setup link is specifically for Browser RUM, and logsSampleRate alone cannot produce renderer log events, so the advertised feature silently sends nothing unless users infer this separate step; include the renderer-side Browser Logs setup or a direct link to it.

AGENTS.md reference: AGENTS.md:L3-L6

Useful? React with 👍 / 👎.