Closed angelstoone closed 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.
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 👍🏻
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.
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 theapplication(_:didFinishLaunchingWithOptions:)
method.Reproduction steps
2.6.0
to latest) into an iOS application.application_start
user actions through the DataDog dashboard.@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 fromprewarming
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