✨ [RUM-18194] default RUM service to the applicationId - #4979
Conversation
When `service` is not configured, fall back to the `applicationId` so RUM events are always attributed to a service. Applied after the tracing check, which still requires an explicitly configured service.
Bundles Sizes Evolution
|
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: dfb1e8b | Docs | View more details | Give us feedback! |
The test fixture app id contained an uppercase character, which is forbidden in tags, so every spec building tags emitted a sanitization warning. CI fails on unexpected console output, unlike the local runner. The profiling e2e asserts the exact tags_profiler string, which now carries the defaulted service.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dfb1e8bda3
ℹ️ 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".
|
|
||
| return { | ||
| ...config, | ||
| service: config.service || config.applicationId, |
There was a problem hiding this comment.
Avoid defaulting bridge sessions to the placeholder application ID
issue: When a mobile/React Native event bridge is present and the web initialization omits service, overrideInitConfigurationForBridge() first replaces the application ID with the synthetic 00000000-aaaa-0000-aaaa-000000000000; this fallback then emits that placeholder as the service on every forwarded RUM event and in profile tags. That prevents these hybrid sessions from retaining an absent service for the native SDK's application-level default and collapses their attribution under the placeholder, so bridge configurations should preserve an omitted service unless the customer explicitly supplied one.
Useful? React with 👍 / 👎.
Motivation
RUM events from apps that never set
servicearrive with no service attribution at all. The mobile SDKs already fall back to something sensible (iOS uses the bundle identifier, Android the manifest application ID), browser was the odd one out.Changes
When
serviceis not configured, it now falls back to theapplicationId.The fallback is applied after the
allowedTracingUrlscheck, not before, so tracing still refuses to start without an explicitly configured service. That check would otherwise become unreachable and apps would silently start injecting trace headers pointing at a service name that matches nothing in APM.Logs is untouched. It has no
applicationIdof its own, andRumInternalContextdoesn't carryservice, so nothing leaks across when both SDKs run.Test instructions
applicationId: '0a1b2c3d-4e5f-6789-abcd-ef0123456789'insandbox/index.htmland leaveserviceoutyarn devand open http://localhost:8080window.__ddBrowserSdkExtensionCallback = (msg) => console.log(msg.payload.type, msg.payload.service, msg.payload.ddtags)service: '0a1b2c3d-...'andddtagscontainsservice:0a1b2c3d-...DD_RUM.getInitConfiguration().serviceis still undefined, the default should not leak into the getterDD_LOGS.logger.info('test')serviceand itsddtagsis onlysdk_version:devallowedTracingUrls: ['http://localhost:8080']and removeserviceChecklist
DEFAULT_RUM_CONFIGURATIONsets noservice, soprofiling.scenario.tsnow asserts the defaulted value end to end intags_profiler.