Skip to content

RUMM-2625 Update default values for RUM events#1139

Merged
plousada merged 4 commits into
developfrom
plousada/RUMM-2625/standardize-rum-event-defaults
Nov 14, 2022
Merged

RUMM-2625 Update default values for RUM events#1139
plousada merged 4 commits into
developfrom
plousada/RUMM-2625/standardize-rum-event-defaults

Conversation

@plousada

@plousada plousada commented Nov 9, 2022

Copy link
Copy Markdown
Member

What does this PR do?

Updates some default attributes of RUM events in order to standardize and unify behaviour across all sdk platforms.

Motivation

What inspired you to submit this pull request?

Additional Notes

Anything else we should know when reviewing?

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)

@plousada
plousada requested a review from a team as a code owner November 9, 2022 12:09
@xgouchet xgouchet added the size-medium This PR is medium sized label Nov 9, 2022
@plousada
plousada force-pushed the plousada/RUMM-2625/standardize-rum-event-defaults branch 4 times, most recently from f14b51a to ed65701 Compare November 9, 2022 17:38
@codecov-commenter

codecov-commenter commented Nov 9, 2022

Copy link
Copy Markdown

Codecov Report

Merging #1139 (9b9cc1e) into develop (931b063) will decrease coverage by 0.16%.
The diff coverage is 83.33%.

❗ Current head 9b9cc1e differs from pull request most recent head 3fb947c. Consider uploading reports for the commit 3fb947c to get more accurate results

@@             Coverage Diff             @@
##           develop    #1139      +/-   ##
===========================================
- Coverage    83.17%   83.02%   -0.16%     
===========================================
  Files          274      275       +1     
  Lines         9462     9528      +66     
  Branches      1540     1556      +16     
===========================================
+ Hits          7870     7910      +40     
- Misses        1152     1162      +10     
- Partials       440      456      +16     
Impacted Files Coverage Δ
...datadog/android/core/internal/utils/UserInfoExt.kt 50.00% <50.00%> (ø)
...android/rum/internal/ndk/DatadogNdkCrashHandler.kt 86.39% <63.64%> (-1.18%) ⬇️
...roid/rum/internal/domain/scope/RumResourceScope.kt 96.02% <78.95%> (-1.91%) ⬇️
.../android/rum/internal/domain/scope/RumViewScope.kt 95.45% <82.98%> (-1.24%) ⬇️
...ndroid/rum/internal/domain/scope/RumActionScope.kt 97.18% <86.67%> (-1.32%) ⬇️
...g/android/rum/internal/domain/scope/RumEventExt.kt 94.01% <100.00%> (+0.81%) ⬆️
...android/log/internal/logger/TelemetryLogHandler.kt 75.00% <0.00%> (-25.00%) ⬇️
...ndroid/telemetry/internal/TelemetryEventHandler.kt 66.96% <0.00%> (-5.36%) ⬇️
...droid/rum/tracking/ActivityViewTrackingStrategy.kt 86.54% <0.00%> (-1.92%) ⬇️
...rc/main/java/com/datadog/opentracing/DDTracer.java 55.65% <0.00%> (-0.42%) ⬇️
... and 1 more

session = ViewEvent.DdSession(plan = ViewEvent.Plan.PLAN_1)
)
),
connectivity = networkInfo.toViewConnectivity(),

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Why are we adding the network info on the View? It was not added on purpose, since the network info can change many times during a View's lifetime. AFAIK the last value will override previous ones, meaning that having this information will be erroneous and unusable.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I had considered it would be useful to get the last connectivity value the view had instead of no information, but like you said it's probably not all that actionable and most insight can already be taken from resource connectivity values. I'll remove it.

if (trackFrustrations && errorCount > 0 && actualType == RumActionType.TAP) {
frustrations.add(ActionEvent.Type.ERROR_TAP)
}
val networkInfo = CoreFeature.networkInfoProvider.getLatestNetworkInfo()

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

for continuous action network info at the time of sending the action may be not relevant or not the same as it was at the beginning of the action. Like for the RumResourceScope we fix the network info when we create resource scope, because this is the state when that was when resource call started.

IMO we should either do the same here, or not add it.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I'll follow the same pattern as in RumResourceScope, it makes more sense.

)
}

internal fun NetworkInfo.toActionConnectivity(): ActionEvent.Connectivity {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

If we are going to add network info for actions, it would be nice to add tests.


val context = getRumContext()
val user = CoreFeature.userInfoProvider.getUserInfo()
val hasUserInfo = user.id != null || user.name != null ||

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

should we maybe extract it into extension/util method? the same check occurs multiple times in this PR

}

fun hasNoUserInfo(): ErrorEventAssert {
assertThat(actual.usr).isNull()

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

minor: we can also add error message


whenever(coreFeature.mockUserInfoProvider.getUserInfo()) doReturn fakeUserInfo
whenever(mockParentScope.getRumContext()) doReturn fakeParentContext
whenever(coreFeature.mockNetworkInfoProvider.getLatestNetworkInfo()) doReturn fakeAndroidNetworkInfo

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

We need to add the assertions for the changed/added fields. Same for other tests.

@plousada
plousada force-pushed the plousada/RUMM-2625/standardize-rum-event-defaults branch from ed65701 to 240b52e Compare November 10, 2022 17:54
@xgouchet xgouchet added the size-large This PR is large sized label Nov 11, 2022
@plousada plousada removed the size-medium This PR is medium sized label Nov 11, 2022

@mariusc83 mariusc83 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

LGTM

@0xnm 0xnm left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

lgtm! I've added one suggestion (the same assertion is repeated twice).

Comment on lines +4532 to +4533
hasServiceName(coreFeature.fakeServiceName)
hasVersion(coreFeature.mockAppVersionProvider.version)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Same assertion twice

Suggested change
hasServiceName(coreFeature.fakeServiceName)
hasVersion(coreFeature.mockAppVersionProvider.version)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Nice spot, thank you.

@plousada
plousada force-pushed the plousada/RUMM-2625/standardize-rum-event-defaults branch from 9b9cc1e to 3fb947c Compare November 14, 2022 11:25
@plousada
plousada merged commit 8ddbd15 into develop Nov 14, 2022
@plousada
plousada deleted the plousada/RUMM-2625/standardize-rum-event-defaults branch November 14, 2022 15:27
@xgouchet xgouchet added this to the 1.16.0 milestone Dec 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size-large This PR is large sized

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants