DataDog / dd-sdk-ios

Datadog SDK for iOS - Swift and Objective-C.
Apache License 2.0
196 stars 124 forks source link

Almost no `application_start` user actions with a `@action.loading_time > 0` when bumping from 2.5.1 to 2.10.1 #1974

Closed angelstoone closed 1 month ago

angelstoone commented 1 month ago

Describe the bug

Our app relies on the application_start user actions @action.loading_time to measure the App Start performance.

However, after updating from version 2.5.1 to 2.10.1, I noticed an extremely low frequency (almost no events) of these actions having a @action.loading_time greater than 0. Even after updating to the latest version (2.14.1), the issue persists.

We initialize the SDK in the AppDelegate within the application(_:didFinishLaunchingWithOptions:) method.

Reproduction steps

  1. Integrate the DataDog SDK (version 2.6.0 to latest) into an iOS application.
  2. Monitor the application_start user actions through the DataDog dashboard.
  3. Observe the @action.loading_time values recorded for these actions.

SDK logs

No response

Expected behavior

The application_start user actions should consistently have a @action.loading_time greater than 0 (aside from prewarming I believe), reflecting the actual loading time of the application.

Affected SDK versions

2.5.1 < version <= 2.10.1

Latest working SDK version

2.5.1

Did you confirm if the latest SDK version fixes the bug?

Yes

Integration Methods

Cocoapods

Xcode Version

15.4

Swift Version

No response

MacOS Version

No response

Deployment Target

iOS 15

Device Information

No response

Other relevant information

No response

ncreated commented 1 month ago

Hey @angelstoone 🙂 👋. I tried verifying this observation in our internal apps, but I cannot confirm the behaviour. I'm seeing @action.loading_time being consistently present for all actions that have no @context.active_pre_warm value set. All our apps do use latest version of the SDK.

Expected behavior

The application_start user actions should consistently have a @action.loading_time greater than 0 (aside from prewarming I believe), reflecting the actual loading time of the application.

That is correct expectation 👍.

@angelstoone, you can check this query:

@action.type:application_start -@action.loading_time:* -@context.active_pre_warm:* 

to filter all application_start actions that have no loading_time and no active_pre_warm flag set. The list should be empty or close to empty (anticipating false-positives from debug environment etc.).

Because we can't reproduce this problem and it relates to data in your org, I'll suggest you to contact our support engineers at https://www.datadoghq.com/support/ for more curated help.

angelstoone commented 1 month ago

Hi @ncreated 👋🏻

I tried verifying this observation in our internal apps, but I cannot confirm the behaviour. I'm seeing @action.loading_time being consistently present for all actions that have no @context.active_pre_warm value set. All our apps do use latest version of the SDK.

Thanks a lot for checking 😃

@action.type:application_start -@action.loading_time: -@context.active_pre_warm: to filter all application_start actions that have no loading_time and no active_pre_warm flag set. The list should be empty or close to empty (anticipating false-positives from debug environment etc.).

Regarding this query, this query is indeed resulting in an empty list (thanks for sharing because I learnt that we have the prewarming field that we can query 😄). Still, I made an interesting discovery, is it normal that in our apps all application_start user actions have @context.active_pre_warm equal to true 🤔?!

Because we can't reproduce this problem and it relates to data in your org, I'll suggest you to contact our support engineers at https://www.datadoghq.com/support/ for more curated help.

Thanks, I will be reaching out 👍🏻

ncreated commented 1 month ago

Still, I made an interesting discovery, is it normal that in our apps all application_start user actions have @context.active_pre_warm equal to true 🤔?

It is not expected. Only pre-warmed sessions should have this parameter set (and no loading_time). The actual volume of pre-warmed sessions is specific to app and user behaviors, so there's no single answer to how many you should expect to see. Clearly however, there should be also some not-prewarmed sessions on your list with loading_time set.

Like said, please loop this issue through our support channel, so we can provide more curated help. For now I'll close this issue, but feel free to ask more questions on the matter if necessary.