-
Notifications
You must be signed in to change notification settings - Fork 74
RUM-10770: Remove KeepAlive event in RUM #3079
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -108,7 +108,8 @@ internal class RumViewManagerScope( | |
| delegateToChildren(event, datadogContext, writeScope, writer) | ||
|
|
||
| if (event is RumRawEvent.StartView && !stopped) { | ||
| startForegroundView(event, datadogContext, writeScope, writer) | ||
| startForegroundView(event) | ||
| sendViewUpdateToChildren(event, datadogContext, writeScope, writer) | ||
| lastStoppedViewTime?.let { | ||
| val gap = event.eventTime.nanoTime - it.nanoTime | ||
| if (gap in 1 until THREE_SECONDS_GAP_NS) { | ||
|
|
@@ -176,6 +177,15 @@ internal class RumViewManagerScope( | |
| childrenScopes.add(viewScope) | ||
| } | ||
|
|
||
| private fun sendViewUpdateToChildren( | ||
| event: RumRawEvent, | ||
| datadogContext: DatadogContext, | ||
| writeScope: EventWriteScope, | ||
| writer: DataWriter<Any> | ||
| ) { | ||
| childrenScopes.forEach { it.sendViewUpdate(event, datadogContext, writeScope, writer) } | ||
| } | ||
|
Comment on lines
+180
to
+187
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. suggestion: let's avoid having this method, because
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this is not only for tests right now, it is also called to update the view event when creating a new foreground view (before it was updated by keep alive).
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is still mainly for tests, because such usage in production code is a small workaround which shouldn't be used in general: there may be some logic between |
||
|
|
||
| @WorkerThread | ||
| private fun delegateToChildren( | ||
| event: RumRawEvent, | ||
|
|
@@ -262,10 +272,7 @@ internal class RumViewManagerScope( | |
|
|
||
| @WorkerThread | ||
| private fun startForegroundView( | ||
| event: RumRawEvent.StartView, | ||
| datadogContext: DatadogContext, | ||
| writeScope: EventWriteScope, | ||
| writer: DataWriter<Any> | ||
| event: RumRawEvent.StartView | ||
| ) { | ||
| val viewScope = RumViewScope.fromEvent( | ||
| parentScope = this, | ||
|
|
@@ -289,7 +296,6 @@ internal class RumViewManagerScope( | |
| ) | ||
| applicationDisplayed = true | ||
| childrenScopes.add(viewScope) | ||
| viewScope.handleEvent(RumRawEvent.KeepAlive(), datadogContext, writeScope, writer) | ||
| viewChangedListener?.onViewChanged( | ||
| RumViewInfo( | ||
| key = event.key, | ||
|
|
@@ -428,7 +434,6 @@ internal class RumViewManagerScope( | |
|
|
||
| internal val silentOrphanEventTypes = arrayOf<Class<*>>( | ||
| RumRawEvent.ApplicationStarted::class.java, | ||
| RumRawEvent.KeepAlive::class.java, | ||
| RumRawEvent.ResetSession::class.java, | ||
| RumRawEvent.StopView::class.java, | ||
| RumRawEvent.ActionDropped::class.java, | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this change will trigger zero view duration telemetry
dd-sdk-android/features/dd-sdk-android-rum/src/main/kotlin/com/datadog/android/rum/internal/domain/scope/RumViewScope.kt
Lines 1361 to 1371 in f7fffa7
This is because the time of the scope creation matches event for view update time. And then we will set view duration to 1ns, which may be very puzzling when exploring the telemetry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it the case already before the PR? here we try to align with the existing logic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, here is a minor change of behavior: before it was
KeepAliveevent which was used to send view update and which is created after the original event used to create view scope, so the duration was always positive. Now it is the same event as it was used to create view scope, so the duration is now zero for such initial view update.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we remove
KeepAliveevent and callsendViewUpdatedirectly, indeed, the view duration becomes 1ns after the creation. But this is somehow aligned to the existing IOS logic after checking with IOS team, because if the view is the last view in the session and it doesn't have any sub events which can update it, we still need to report this view event, and we will use this duration as thetime_spent.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If 0 -> 1ns is a legitimate view duration for such case you still have to deal with the logging I mentioned above, because it shouldn't log in this case (especially taking into account that it also logs to telemetry, it will blow up the telemetry volume).