RUMM-2767 Handle SR requests through SessionReplayRequestsFactory#1176
Conversation
f1c7ac1 to
5a43262
Compare
0b711b5 to
0fe31e3
Compare
351eae5 to
7a0b30f
Compare
Codecov Report
@@ Coverage Diff @@
## feature/sdkv2 #1176 +/- ##
=================================================
+ Coverage 82.09% 83.27% +1.17%
=================================================
Files 355 355
Lines 11973 11957 -16
Branches 2049 2058 +9
=================================================
+ Hits 9829 9956 +127
+ Misses 1506 1359 -147
- Partials 638 642 +4
|
| // TODO: RUMM-2397 Add the proper logs here once the sdkLogger will be added | ||
| // the data in the batch is corrupted. We return an empty request just to make | ||
| // sure the batch will be deleted by the core. | ||
| return getEmptyRequest() |
There was a problem hiding this comment.
should we maybe change RequestFactory signature to allow null return value? Otherwise this case looks like a hack, which will also trigger some telemetry.
There was a problem hiding this comment.
I think this will be nice if we can do so.
There was a problem hiding this comment.
Yes, empty request looks like a hack and we shouldn't even make an attempt to send it.
ed8677c to
bd95086
Compare
bd95086 to
211a0eb
Compare
| // TODO: RUMM-2397 Add the proper logs here once the sdkLogger will be added | ||
| // the data in the batch is corrupted. We return an empty request just to make | ||
| // sure the batch will be deleted by the core. | ||
| return getEmptyRequest() |
There was a problem hiding this comment.
Yes, empty request looks like a hack and we shouldn't even make an attempt to send it.
|
|
||
| if (startTimestamp == null || stopTimestamp == null) { | ||
| // this is just to avoid having kotlin warnings but the elements | ||
| // without timestamp property were already removed int the logic above |
There was a problem hiding this comment.
| // without timestamp property were already removed int the logic above | |
| // without timestamp property were already removed in the logic above |
57491fe to
e4c4d1d
Compare
0xnm
left a comment
There was a problem hiding this comment.
LGTM. I've added few suggestions, but they are not blocking for me.
The only concern is "empty request" thing, but let's create another task to do something with it eventually.
| - "kotlin.collections.MutableSet.map(kotlin.Function1)" | ||
| - "kotlin.collections.MutableSet.remove(java.io.File)" | ||
| - "kotlin.collections.MutableSet.remove(com.datadog.android.v2.core.internal.storage.ConsentAwareStorage.Batch)" | ||
| - "kotlin.collections.Iterable.toMap(kotlin.collections.MutableMap)" |
There was a problem hiding this comment.
minor: should go up, to L1058 (where Iterable is declared)
There was a problem hiding this comment.
Actually that's a duplicate from a rebase :)
| private fun JsonObject.records(): JsonArray? { | ||
| return get(EnrichedRecord.RECORDS_KEY)?.asJsonArray | ||
| } | ||
|
|
||
| private fun JsonObject.timestamp(): Long? { | ||
| return getAsJsonPrimitive(TIMESTAMP_KEY)?.asLong | ||
| } | ||
|
|
||
| private fun JsonObject.rumContext(): SessionReplayRumContext? { | ||
| val applicationId = get(EnrichedRecord.APPLICATION_ID_KEY)?.asString | ||
| val sessionId = get(EnrichedRecord.SESSION_ID_KEY)?.asString | ||
| val viewId = get(EnrichedRecord.VIEW_ID_KEY)?.asString |
There was a problem hiding this comment.
these methods can still throw json related exceptions and they are not covered by try-catch
| import org.mockito.quality.Strictness | ||
|
|
||
| @Extensions( | ||
| ExtendWith(MockitoExtension::class), |
There was a problem hiding this comment.
minor: we don't really need this one (and MockitoSettings annotation as well), because we don't mock anything in this test.
| override fun getForgery(forge: Forge): JsonObject { | ||
| return JsonObject().apply { | ||
| val fieldCount = forge.aTinyInt() | ||
| for (i in 0..fieldCount) { |
There was a problem hiding this comment.
| for (i in 0..fieldCount) { | |
| repeat(fieldCount + 1) { |
295508b to
0549eb2
Compare
0549eb2 to
347b709
Compare
What does this PR do?
As a follow up task on the RFC in this PR we are handling the SR data upload requests through the
SessionReplayRequestFactory. Also we are making sure that the new events are stored in a new batch whenever the RUMcontextchanged.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)