feat: Provide a method for late initialization of URLSessionTracking

[fuzzybinary]

What and why?

This is for a limited use case of people that need to initialize native URL session tracking after RUM has been initialized.

refs: RUM-2525

How?

The approach here is a bit weird because of the need to include some providers (the Trace ID generator and the date provider) in the configuration. We really only override these in unit tests, and they're internal, but I needed to provide a way to include the overrides, hence the new Configuration.LateURLSessionTracking object.

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

Custom CI job configuration (optional)

• Run unit tests for Core, RUM, Trace, Logs, CR and WVT
• Run unit tests for Session Replay
• Run integration tests
• Run smoke tests
• Run tests for tools/

[datadog-datadog-prod-us1]

Datadog Report

Branch report: jward/RUM-2525-late-url-session-instrumentation
Commit report: daf7ca5

✅ dd-sdk-ios: 0 Failed, 0 New Flaky, 2507 Passed, 0 Skipped, 21m 18.82s Wall Time

[ganeshnj]

A bit lost with the requirement of this change. Do you have a code example where the current version doesn't work.

In current available version, either RUM or Tracing must be enabled to enable URLSession tracking.

[fuzzybinary]

@ganeshnj This is a very strange use case of a Flutter user that uses native iOS URLSessions. Flutter initializes Datadog and RUM, but they need a way to enable URLSession tracking after initialization has been performed.

[ganeshnj]

@ganeshnj This is a very strange use case of a Flutter user that uses native iOS URLSessions. Flutter initializes Datadog and RUM, but they need a way to enable URLSession tracking after initialization has been performed.

I see, I wonder if we could use the existing config type with default values and extend it with implementations that you want to inject, because this type will go to public type (in auto completions et all) and makes the API unintuitive.

[fuzzybinary]

@ganeshnj I'm not sure how to do this cleanly without a new type or by adding more parameters to enableURLSessionTracking. Do you have an example of how you'd structure it?

Alternatively, we could put LateURLSessionTracking under another wrapper Internal or __Internal to avoid it showing up at the top level of autocomplete?

[maxep]

Nice, thank you for the changes and the fuzzy tests 🙏

[ncreated]

This list of parameters seems wrong 🖐️

[ncreated]

question/ Have we considered changing this to following?

    public static func enableURLSessionTracking(
        with urlSessionTrackingConfiguration: RUM.Configuration.URLSessionTracking,
        rumConfiguration: RUM.Configuration,
        in core: DatadogCoreProtocol = CoreRegistry.default) throws {

Effectively, this way we won't need to introduce new LateURLSessionTracking nor duplicate any properties. The trade-off will be on the caller-side (in Flutter), where we'll need to supply this method both configurations:

• RUM.Configuration.URLSessionTracking
• RUM.Configuration

For the sake of streamlining RUM init, the cost seems worth it. WDYT?

[fuzzybinary]

I'm concerned with requiring RUM.Configuration because of the number of parameters available that just aren't used, especially the non-optional parameters that wouldn't actually have an affect.

Remember "on the Flutter side" in this case is a client who has to make sense of the API, and requiring the RUM.Configuration when only a few parameters out of it are going to be used worries me. I'm open to discuss it though.

[ncreated]

I see 👍. One more idea that comes to my mind is attaching RUM.Configuration to RUMFeature, so we can retrieve it "after" by ourselves without requiring the client to pass it:

public static func enableURLSessionTracking(
   with urlSessionTrackingConfiguration: RUM.Configuration.URLSessionTracking,
   in core: DatadogCoreProtocol = CoreRegistry.default
) throws {
   guard let rum = core.get(feature: RUMFeature.self) else {
      throw ProgrammerError(
         description: "RUM must be initialized before calling `RUM.enableUrlSessionTracking`."
      )
   }
   let rumConfiguration = rum.configuration // <-- ⭐️ new thing
   // ...

This isn't a change request. Using separate LateURLSessionTracking type makes sense as well 👍.

[datadog-datadog-prod-us1]

Datadog Report

Branch report: jward/RUM-2525-late-url-session-instrumentation
Commit report: 7e58f00

✅ dd-sdk-ios: 0 Failed, 0 New Flaky, 2529 Passed, 0 Skipped, 20m 30.17s Wall Time

[ncreated]

I see 👍. One more idea that comes to my mind is attaching RUM.Configuration to RUMFeature, so we can retrieve it "after" by ourselves without requiring the client to pass it:

public static func enableURLSessionTracking(
   with urlSessionTrackingConfiguration: RUM.Configuration.URLSessionTracking,
   in core: DatadogCoreProtocol = CoreRegistry.default
) throws {
   guard let rum = core.get(feature: RUMFeature.self) else {
      throw ProgrammerError(
         description: "RUM must be initialized before calling `RUM.enableUrlSessionTracking`."
      )
   }
   let rumConfiguration = rum.configuration // <-- ⭐️ new thing
   // ...

This isn't a change request. Using separate LateURLSessionTracking type makes sense as well 👍.

[fuzzybinary]

I would actually prefer adding the configuration to the feature if we're good with that.

[fuzzybinary]

Changed to saving the configuration. It's much cleaner, even if it does mean holding onto some extra info.

[ncreated]

LGTM 👍. Thanks for extra efforts on simplification 🙂