RUMM-924 Introduce the new InternalLogger#metric API#1581
Conversation
| ) | ||
|
|
||
| /** | ||
| * Logs a metric from the internal implementation. |
There was a problem hiding this comment.
what is the meaning of internal implementation here? Also maybe we need to add the statement that metric will be sent to the telemetry (and say how), because from the method arguments it is not evident where is the metric here.
| } | ||
| rumFeature.sendEvent(telemetryEvent) | ||
| } | ||
| private fun logMetric( |
There was a problem hiding this comment.
| private fun logMetric( | |
| private fun logMetric( |
| testedInternalLogger.metric( | ||
| mockLambda, | ||
| fakeAdditionalProperties | ||
| ) |
There was a problem hiding this comment.
What is the point of the test without verification part?
There was a problem hiding this comment.
I cannot verify anything there, I wanted to make sure is not throwing anything...maybe there is a method to assert that isNotThrowing
There was a problem hiding this comment.
you can wrap the invocation in assertNotThrows.
There was a problem hiding this comment.
yup, that's what I also have in mind ;)
| (GlobalRumMonitor.get(sdkCore) as? AdvancedRumMonitor) | ||
| ?.sendDebugTelemetryEvent(message, additionalProperties) | ||
| } | ||
| fun metric(message: String, additionalProperties: Map<String, Any?>? = null) { |
There was a problem hiding this comment.
| fun metric(message: String, additionalProperties: Map<String, Any?>? = null) { | |
| fun metric(message: String, additionalProperties: Map<String, Any?>? = null) { |
| val eventIdentity = event.identity | ||
|
|
||
| if (seenInCurrentSession.contains(eventIdentity)) { | ||
| if (!event.isMetric && seenInCurrentSession.contains(eventIdentity)) { |
There was a problem hiding this comment.
do we have a risk of sending too much metrics by disabling this check and thus adding a lot of pressure on the storage and also on the Datadog servers?
There was a problem hiding this comment.
I was following what was done in iOS here. I guess the risk was assessed already there, in the end we are going to have an extra sampler in the MetricsDispatcher which will come in the next PR. We have a 15% extra sampler there.
| } | ||
|
|
||
| @Test | ||
| fun `𝕄 handle metric event 𝕎 onReceive(){no additionalProperties}`( |
There was a problem hiding this comment.
probably test with missing message is missing
| val fakeAdditionalProperties = forge.exhaustiveAttributes() | ||
| testedFeature.onInitialize(appContext.mockInstance) | ||
| val event = mapOf( | ||
| "type" to "mobile_metric", |
There was a problem hiding this comment.
minor: "mobile_metric" is hardcoded in the tests in several places - perhaps it could be taken from a constant so as to only change in one place in future if the value changed?
cfde8e0 to
35e8143
Compare
| } | ||
|
|
||
| @Test | ||
| fun `𝕄 send metric 𝕎 metric`( |
There was a problem hiding this comment.
| fun `𝕄 send metric 𝕎 metric`( | |
| fun `𝕄 send metric 𝕎 metric()`( |
| * @param messageBuilder the lambda building the metric message | ||
| * @param additionalProperties additional properties to add to the metric | ||
| */ | ||
| fun metric(messageBuilder: () -> String, additionalProperties: Map<String, Any?>) |
There was a problem hiding this comment.
Function name should be action verbs. We should consider logMetric. Alternatively, we could instead use an InternalLogger.Level.METRIC instead, and reuse the existing top level methods. WDYT?
There was a problem hiding this comment.
i'd rather keep a new method here to match what iOS added in the InternalLogger but will change it to logMetric
b2af158 to
c2f62d2
Compare
0xnm
left a comment
There was a problem hiding this comment.
lgtm. I left some comments, but they are not blocking.
| public static final field Companion Lcom/datadog/android/api/InternalLogger$Companion; | ||
| public abstract fun log (Lcom/datadog/android/api/InternalLogger$Level;Lcom/datadog/android/api/InternalLogger$Target;Lkotlin/jvm/functions/Function0;Ljava/lang/Throwable;ZLjava/util/Map;)V | ||
| public abstract fun log (Lcom/datadog/android/api/InternalLogger$Level;Ljava/util/List;Lkotlin/jvm/functions/Function0;Ljava/lang/Throwable;ZLjava/util/Map;)V | ||
| public abstract fun metric (Lkotlin/jvm/functions/Function0;Ljava/util/Map;)V |
There was a problem hiding this comment.
yeah it is something wrong with the api generation as I already ran that method 🤔
| * Logs a specific metric from the internal implementation. The metric will leverage the new | ||
| * added additionalProperties in the |
There was a problem hiding this comment.
I'm still not quite clear with the description. Does internal implementation mean from SDK-related code only? Also I guess there is a typo in new added, and not quite clear how additionalProperties will be leveraged. Maybe we can say that metric data (type, values, etc.) will be taken from additionalProperties? This way it is more clear imo.
There was a problem hiding this comment.
the internal implementation is present in all the other methods description so I just followed the pattern. And yes for me it means that is meant for internal usage inside the SDK code. I will try to update the last part there ;)
c2f62d2 to
ac0ffa6
Compare
Codecov Report
@@ Coverage Diff @@
## develop #1581 +/- ##
===========================================
- Coverage 83.37% 83.34% -0.04%
===========================================
Files 437 437
Lines 14910 14942 +32
Branches 2230 2237 +7
===========================================
+ Hits 12431 12452 +21
- Misses 1885 1894 +9
- Partials 594 596 +2
|
ac0ffa6 to
71a10da
Compare
71a10da to
409b4e0
Compare
What does this PR do?
A brief description of the change being made with this pull request.
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)