[amortemousque]

Motivation

Microfrontend applications use service and version attribution to identify which MFE generated a RUM event. Existing attribution relies on application stack traces to resolve build-plugin metadata or let customers match bundle URLs in beforeSend.

Automatic click actions lack an application handling stack, so clicks within an MFE cannot use these attribution mechanisms and remain attributed to the shell application. Associating a stack captured from the MFE's bundle with its DOM container lets clicks on that container and its descendants reuse the existing attribution logic, without requiring customers to duplicate service and version values in their application code.

Changes

• Add DD_RUM.attachElementStack(element) to RUM and RUM Slim. Capture the caller's stack at the public API entry point and immediately register it in an instance-owned WeakMap, including before init(). Registrations survive startup without buffering or retaining detached elements strongly.
• Snapshot the closest registered target/ancestor stack at pointerdown, crossing shadow roots. Re-registration affects future actions; ongoing actions and rage-click groups retain their initial stack.
• Resolve service/version through existing source-code metadata and expose context.elementStack in beforeSend for manual attribution. Keep stacks out of serialized events and preserve shell fallback.

Test instructions

The new scenarios can be run after building the SDK and test apps:

yarn build
yarn build:apps --app microfrontend --app vanilla
yarn test:e2e microfrontend.scenario.ts -g 'with element stacks' --project chromium --project firefox --project webkit

Checklist

• Tested locally
• Tested on staging
• Added unit tests for this change.
• Added e2e/integration tests for this change.
• Updated documentation and/or relevant AGENTS.md file (API JSDoc and approved design)

[datadog-prod-us1-6]

 

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 75.00%
• Overall Coverage: 77.31% (-0.01%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 977b623 | Docs | View more details | Give us feedback!}

[cit-pr-commenter-54b7da]

Bundles Sizes Evolution

📦 Bundle Name	Base Size	Local Size	𝚫	𝚫%	Status
Rum Salesforce	191.13 KiB	191.54 KiB	+418 B	+0.21%	✅
Rum	191.11 KiB	191.52 KiB	+418 B	+0.21%	✅
Rum Salesforce Profiler	8.35 KiB	8.35 KiB	0 B	0.00%	✅
Rum Profiler	8.35 KiB	8.35 KiB	0 B	0.00%	✅
Rum Salesforce Recorder	32.04 KiB	32.04 KiB	0 B	0.00%	✅
Rum Recorder	32.04 KiB	32.04 KiB	0 B	0.00%	✅
Logs	60.10 KiB	60.10 KiB	0 B	0.00%	✅
Rum Slim	147.27 KiB	147.66 KiB	+399 B	+0.26%	✅
Worker	24.23 KiB	24.23 KiB	0 B	0.00%	✅
Rum Shopify	221.56 KiB	221.97 KiB	+418 B	+0.18%	✅
Rum Shopify Profiler	8.35 KiB	8.35 KiB	0 B	0.00%	✅
Rum Shopify Recorder	4.85 KiB	4.85 KiB	0 B	0.00%	✅

[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-11-03T14:53:04.541050Z	977b623	New commits
🔒 Security Review	✅ Completed 2026-11-03T14:53:51.345715Z	977b623	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: 65086b87d4

ℹ️ 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".

[datadog-prod-us1-6]

More details

Element stacks are stored per SDK instance and snapshotted at pointerdown, preserving attribution for ongoing actions while keeping stacks out of serialized events. The completed static review found no reportable defects.

Was this helpful? React 👍 or 👎

_{Open Bits AI session}

_{🤖 Bits Code Review · Commit 65086b8}

[BeltranBulbarellaDD]

LGTM!

[bcaudan]

💭 thought: ‏elementStacks is passed through startRum / startRumEventCollection only to reach the action domain. What if actionCollection owned it and exposed attachElementStack through the strategy, like addAction? To keep the current guarantees (no buffering, weak references before init), preStartRum could keep its own WeakMap for calls made before init and hand it to actionCollection when RUM starts, instead of replaying the calls through bufferApiCalls.

[bcaudan]

💬 suggestion: ‏A non-Element argument (e.g. null from a getElementById that ran too early) makes WeakMap.set throw. callMonitored swallows it, so JS/CDN customers get no feedback, clicks stay attributed to the shell, and we receive it as an SDK error in telemetry. Could we warn and ignore, like sanitizeStringOption does?

[bcaudan]

🥜 nitpick: ‏rawRumEvent.type === 'action' looks redundant: only RumActionEventDomainContext declares elementStack, so the in check alone already narrows to actions.