You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The renderer already gets custom actions from the bundled Browser SDK, but the main process had no equivalent. This adds addAction on the main-process side so customers can record custom actions that never touch the DOM, native menu/tray clicks, auto-update steps, background workflows.
Changes
Add ActionCollection , addAction(name, context?) emits a custom RUM action attached to the current main-process view. Wired into RumCollection and exported from the public entry, with a RawRumAction raw type and the RumActionEvent type export.
Context passed directly (like the Browser SDK and mobile attributes), not wrapped in an options object.
Events flow through the existing main-process assembly hooks; ViewCollection already increments view.action.count.
yarn test:e2e --project=e2e action.scenario , asserts a custom action reaches the intake with the given name/context and full RUM context (session, view, application, source: electron).
Checklist
Tested locally (playground)
Added unit tests for this change.
Added e2e/integration tests for this change.
Updated related documentation.
Agentic code review findings addressed or explicitly dismissed.
Add addAction(name, context?) on the main-process side, emitting a custom
RUM action attached to the current view. The renderer already gets custom
actions from the Browser SDK; this covers actions that never touch the DOM
(native menus, auto-update, background workflows).
Action names are free text (no validation) and custom actions carry no
frustration/loading_time/counts, matching the Browser, iOS and Android SDKs.
Covered by unit tests and an e2e scenario.
The reason will be displayed to describe this comment to others. Learn more.
Stale comment
PR Review — Score: 4.4 / 5
This is a well-scoped feature that mirrors existing main-process collection patterns (ErrorCollection, OperationCollection) and wires cleanly through RumCollection → MainAssembly → intake, with thorough unit coverage and a focused e2e scenario. I would approve once customer-facing docs are added; there are no blocking correctness or concurrency concerns in the implementation.
Why 4.4: The core pipeline is simple, synchronous, and consistent with SDK conventions (callMonitored, EventManager RAW events, assembly hooks, ViewCollection counter updates). Tests exercise payload shape, parity choices (free-text names, no frustration/loading_time), and end-to-end intake delivery with full RUM context.
Why not 5: The public addAction API is not yet documented in README.md (the PR checklist still has docs unchecked), and the e2e scenario has a small inconsistency with the error scenario's context assertion style.
Note: dd-gitlab/e2e and dd-gitlab/integration were still pending when this review was posted; other GitLab jobs had completed.
Findings
[Minor] Missing README docs — addAction is exported but not documented in the customer-facing API section alongside addError.
[Nit] Redundant e2e type cast — RumActionEvent already includes context via CommonProperties; the extra cast is unnecessary.
Add the addAction API section to the README and an @example to its JSDoc
(required for new public APIs), and drop a redundant context cast in the
action e2e scenario. Addresses PR review feedback.
The reason will be displayed to describe this comment to others. Learn more.
Stale comment
PR Review — Score: 4.9 / 5
This is a clean, well-tested addition that mirrors existing main-process collection patterns and is ready to merge. The follow-up commit addressed all prior review feedback (README section, JSDoc @example, simplified e2e context assertion). I would approve.
Why 4.9:ActionCollection is a straightforward synchronous RAW-event emitter consistent with ErrorCollection; wiring through RumCollection → MainAssembly → intake is correct, and ViewCollection already increments view.action.count for main-process SERVER action events. Unit tests cover payload shape, SDK parity choices (free-text names, no frustration/loading_time), and lifecycle; the e2e scenario validates intake delivery with full RUM context.
Why not 5: Playground validation remains unchecked in the PR checklist — the only remaining process item, not a code concern.
Note: All dd-gitlab/* jobs were still pending when this review was posted.
Architectural flow
sequenceDiagram
participant App as Main process app
participant API as addAction (public API)
participant AC as ActionCollection
participant EM as EventManager
participant MA as MainAssembly
participant VC as ViewCollection
participant Intake as RUM intake
App->>API: addAction(name, context?)
API->>AC: callMonitored → emitAction
AC->>EM: RAW RUM action event
EM->>MA: assemble with session/view context
MA->>EM: SERVER RUM action (MAIN)
EM->>VC: increment view.action.count (throttled update)
EM->>Intake: transport assembled action event
Loading
Before: Custom RUM actions were only available in the renderer via the Browser SDK; main-process events (menus, tray, auto-update, background work) had no addAction equivalent.
After:addAction(name, context?) on the main process emits a custom action RAW event that flows through the existing assembly pipeline, attaches to the current main-process view, increments view counters, and reaches intake — matching Browser/iOS/Android semantics for action names and payload shape.
Reduce the ActionCollection class doc to a one-line description, drop the
parity/no-tracking preamble comments in the spec (the describe titles
cover it), and remove the use-case prose from the addAction JSDoc.
The reason will be displayed to describe this comment to others. Learn more.
PR Review — Score: 4.9 / 5
This is a clean, well-tested addition that mirrors existing main-process collection patterns and is ready to merge. All prior review feedback (README section, JSDoc @example, simplified e2e context assertion) remains addressed on the latest head; the follow-up comment-trim commit is cosmetic only. I would approve.
Why 4.9:ActionCollection is a straightforward synchronous RAW-event emitter consistent with ErrorCollection; wiring through RumCollection → MainAssembly → intake is correct, and ViewCollection already increments view.action.count for main-process SERVER action events. Unit tests cover payload shape, SDK parity choices (free-text names, no frustration/loading_time), and lifecycle; the e2e scenario validates intake delivery with full RUM context.
Why not 5: Playground validation remains unchecked in the PR checklist — the only remaining process item, not a code concern.
Architectural flow
sequenceDiagram
participant App as Main process app
participant API as addAction (public API)
participant AC as ActionCollection
participant EM as EventManager
participant MA as MainAssembly
participant VC as ViewCollection
participant Intake as RUM intake
App->>API: addAction(name, context?)
API->>AC: callMonitored → emitAction
AC->>EM: RAW RUM action event
EM->>MA: assemble with session/view context
MA->>EM: SERVER RUM action (MAIN)
EM->>VC: increment view.action.count (throttled update)
EM->>Intake: transport assembled action event
Loading
Before: Custom RUM actions were only available in the renderer via the Browser SDK; main-process events (menus, tray, auto-update, background work) had no addAction equivalent.
After:addAction(name, context?) on the main process emits a custom action RAW event that flows through the existing assembly pipeline, attaches to the current main-process view, increments view counters, and reaches intake — matching Browser/iOS/Android semantics for action names and payload shape.
Emit END_USER_ACTIVITY before the action event so a main-process addAction
after inactivity revives an expired session and is recorded on the new one
instead of being dropped. Matches iOS and Android, which treat a manual
action (custom included) as user activity that renews the session.
Covered by a unit test and an e2e scenario (expire, addAction, assert new session).
Add a "Custom Actions" section that calls addAction over IPC, and a native
Datadog menu whose handlers run addAction / stopSession directly in the main
process — so a custom action can be triggered without any renderer interaction.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
Motivation
The renderer already gets custom actions from the bundled Browser SDK, but the main process had no equivalent. This adds
addActionon the main-process side so customers can record custom actions that never touch the DOM, native menu/tray clicks, auto-update steps, background workflows.Changes
ActionCollection,addAction(name, context?)emits acustomRUM action attached to the current main-process view. Wired intoRumCollectionand exported from the public entry, with aRawRumActionraw type and theRumActionEventtype export.attributes), not wrapped in an options object.ViewCollectionalready incrementsview.action.count.Test instructions
yarn test:unit,ActionCollectionspecs cover payload shape, context defaults, unique ids, free-text names, and no-local-tracking.yarn test:e2e --project=e2e action.scenario, asserts acustomaction reaches the intake with the given name/context and full RUM context (session, view, application,source: electron).Checklist