Skip to content

Conversation

@ambushwork
Copy link
Member

@ambushwork ambushwork commented Dec 29, 2025

What does this PR do?

Main changes for this PR:

  • Remove KeepAlive in RumRawEvent
  • Remove keep alive callback in DatadogRumMonitor

Due to the removal of KeepAlive event, there are some side-effect changes:

  • RumViewScope.sendViewUpdate becomes internal so RumViewManagerScope can call it directly to update the view.
  • startForegroundView used to dispatch a keep alive to update the view, now we call sendViewUpdate directly for the same purpose
  • Many unit tests relied on KeepAlive event to flush the Rum Event into the writer, now we use either StopView to flush them, either we call sendViewUpdate directly from RumViewManagerScope

Motivation

RUM-10770

Review checklist (to be filled by reviewers)

  • Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
  • Make sure you discussed the feature or bugfix with the maintaining team in an Issue
  • Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

@datadog-official
Copy link

datadog-official bot commented Dec 29, 2025

🎯 Code Coverage
Patch Coverage: 83.33%
Overall Coverage: 66.43% (+0.04%)

View detailed report

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 0e4edd9 | Docs | Datadog PR Page | Was this helpful? Give us feedback!

@ambushwork ambushwork force-pushed the yl/remove-keep-alive-event branch from b9e9c18 to 1b2198c Compare December 29, 2025 15:12
@codecov-commenter
Copy link

codecov-commenter commented Dec 29, 2025

Codecov Report

❌ Patch coverage is 75.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 71.37%. Comparing base (714d915) to head (0e4edd9).
⚠️ Report is 269 commits behind head on develop.

Files with missing lines Patch % Lines
...lin/com/datadog/android/rum/internal/RumFeature.kt 0.00% 1 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #3079      +/-   ##
===========================================
- Coverage    71.44%   71.37%   -0.07%     
===========================================
  Files          881      881              
  Lines        32397    32381      -16     
  Branches      5462     5460       -2     
===========================================
- Hits         23144    23111      -33     
- Misses        7710     7722      +12     
- Partials      1543     1548       +5     
Files with missing lines Coverage Δ
...g/android/rum/internal/domain/scope/RumRawEvent.kt 99.44% <ø> (-0.01%) ⬇️
...d/rum/internal/domain/scope/RumViewManagerScope.kt 93.44% <100.00%> (+0.41%) ⬆️
.../android/rum/internal/domain/scope/RumViewScope.kt 94.45% <ø> (+0.19%) ⬆️
.../android/rum/internal/monitor/DatadogRumMonitor.kt 88.17% <ø> (-0.49%) ⬇️
...lin/com/datadog/android/rum/internal/RumFeature.kt 89.90% <0.00%> (-0.29%) ⬇️

... and 34 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@ambushwork ambushwork force-pushed the yl/remove-keep-alive-event branch 2 times, most recently from b7ff1cd to f3b731b Compare December 30, 2025 13:19
@ambushwork ambushwork force-pushed the yl/remove-keep-alive-event branch from f3b731b to 0e4edd9 Compare December 30, 2025 13:40
@ambushwork ambushwork marked this pull request as ready for review December 31, 2025 09:28
@ambushwork ambushwork requested a review from a team as a code owner December 31, 2025 09:28
@ambushwork
Copy link
Member Author

@codex review

@chatgpt-codex-connector
Copy link

Codex Review: Didn't find any major issues. More of your lovely PRs please.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +180 to +187
private fun sendViewUpdateToChildren(
event: RumRawEvent,
datadogContext: DatadogContext,
writeScope: EventWriteScope,
writer: DataWriter<Any>
) {
childrenScopes.forEach { it.sendViewUpdate(event, datadogContext, writeScope, writer) }
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: let's avoid having this method, because sendViewUpdate was made internal only for tests and we probably don't want to advertise calling this, the main entrypoint is still handleEvent. It is better to inline this at the call site.

Copy link
Member Author

Choose a reason for hiding this comment

The 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).

Copy link
Member

Choose a reason for hiding this comment

The 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 handleEvent and sending view update.

Comment on lines +111 to +112
startForegroundView(event)
sendViewUpdateToChildren(event, datadogContext, writeScope, writer)
Copy link
Member

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

sdkCore.internalLogger.log(
InternalLogger.Level.WARN,
listOf(
InternalLogger.Target.USER,
InternalLogger.Target.TELEMETRY
),
{ ZERO_DURATION_WARNING_MESSAGE.format(Locale.US, key.name) },
null,
false,
mapOf("view.name" to key.name)
)

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.

Copy link
Member Author

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

Copy link
Member

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 KeepAlive event 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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we remove KeepAlive event and call sendViewUpdate directly, 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 the time_spent.

Copy link
Member

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).

Comment on lines +111 to +112
startForegroundView(event)
sendViewUpdateToChildren(event, datadogContext, writeScope, writer)
Copy link
Member

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants