RUM-9335 Fix missing app ID in Session Ended metric

[mariedm]

What and why?

This PR fixes the missing application ID in RUM Session Ended telemetry. This can happen when stopping a session manually with RUMMonitor.

How?

For consistency, application ID follows the same override pattern as session ID, using application_id_override which gets transformed to application.id by the TelemetryReceiver.

Review checklist

• Feature or bugfix MUST have appropriate tests (unit, integration)
• Make sure each commit and the PR mention the Issue number or JIRA reference
• Add CHANGELOG entry for user facing changes
• Add Objective-C interface for public APIs (see our guidelines (internal) and run make api-surface)

[datadog-datadog-prod-us1]

Datadog Report

Branch report: mariedm/rum-9335-fix-missing-app-id-in-rse
Commit report: 5f3606a
Test service: dd-sdk-ios

✅ 0 Failed, 1354 Passed, 2606 Skipped, 2m 45.7s Total duration (2m 4.45s time saved)

[ncreated]

food for thought/ While this approach works and reuses the override model originally introduced for sessionIDOverrideKey, I believe the issue with application.id is fundamentally different and could be addressed more cleanly - in a way that benefits the broader codebase.

The original purpose of sessionIDOverrideKey was to reflect session.id in "session ended" telemetry, even after a new session had started. In that case, the RUM context accessed like this (in line 255):

let rum = context.additionalContext(ofType: RUMCoreContext.self)

already reflects the new session’s ID, so we needed a mechanism to override it when reporting data for the previous session.

However, application.id doesn’t suffer from the same timing or state issue. It is static across the lifetime of the SDK. The reason it's missing in this context (line 255) isn’t because it's unavailable - it’s because the call to RUMCoreContext.self is returning nil. That origins here in Monitor.swift, where we explicitly reset the context when no session is active.

So, using applicationIDOverrideKey masks the actual issue and applies a workaround rather than solving the root cause. A more scalable and clean solution might be to make sessionID optional in RUMCoreContext, allowing us to still propagate applicationID even when no session exists. This would likely benefit other scenarios where only partial context is available.

--

I'm not sure how much effort it would take to address this in a more robust way, but it might be worth exploring. That said, if it's non-trivial or time-sensitive, the proposed patch is a reasonable workaround and does solve the immediate problem 👍.

Also cc-ing @maxep and @simaoseica-dd for their opinions.

[simaoseica-dd]

already reflects the new session’s ID, so we needed a mechanism to override it when reporting data for the previous session

Isn't it wrong to have a fallback then? ?? rum?.sessionID

My question here is, what is a TelemetryDebugEvent without an applicationID? It should exist at this point, and incrementing the channels (context + attributes) to add that info will make it redundant without the need for it.