-
Notifications
You must be signed in to change notification settings - Fork 11
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
Remove requirement for supplying appId #874
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #874 +/- ##
==========================================
- Coverage 80.92% 80.82% -0.11%
==========================================
Files 435 436 +1
Lines 11613 11629 +16
Branches 1764 1773 +9
==========================================
+ Hits 9398 9399 +1
- Misses 1437 1443 +6
- Partials 778 787 +9
|
I think exporting in pure OTel is unlikely to happen in the short term given how hard it'll be to get away from needing to send session data in a single payload, but I think no-op-ing the delivery service is, as you said, a good first approach. I think we still need to keep the payload object construction for caching reasons, but we can probably optimize what we store in that case. |
7cfc2ba
to
b373e6b
Compare
b373e6b
to
9339af5
Compare
require(!appId.isNullOrEmpty()) { "Embrace AppId cannot be null or empty." } | ||
logger.logWarning( | ||
"No appId supplied to Embrace. This is required if you want to " + | ||
"send data to Embrace, unless you have configured an OTel exporter." |
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.
can we detect if a user has configured an OTel exporter? if they haven't, i.e. they are sending data to our backend, it would probably be better if this threw an exception rather than issuing a warning log
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.
Maybe in debug? I'm wearying about a bad SDK configuration crashing the app if we threw in prod. Like passing a null into a Kotlin String or annotated @nonnull parameter, even though what they did isn't correct, I don't think we should do that.
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.
FWIW, an OTel exporter has to be configured before the SDK starts, so if we want to detect this case, we probably an.
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.
Maybe in debug? I'm wearying about a bad SDK configuration crashing the app if we threw in prod.
yeah, fair point
...droid-sdk/src/main/java/io/embrace/android/embracesdk/config/behavior/SdkEndpointBehavior.kt
Outdated
Show resolved
Hide resolved
...droid-sdk/src/main/java/io/embrace/android/embracesdk/config/behavior/SdkEndpointBehavior.kt
Outdated
Show resolved
Hide resolved
...-android-sdk/src/main/java/io/embrace/android/embracesdk/injection/EssentialServiceModule.kt
Show resolved
Hide resolved
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.
LGTM in general. I like Fredric's suggestion of returning empty strings instead of invalid URLs - but nothing blocking from my side
8b156f8
to
dfee5c0
Compare
dfee5c0
to
03b35cc
Compare
Goal
Removes the requirement for supplying appId. This will allow folks to send data from Embrace to 3rd party OTel exporters without needing to send anything to Embrace's servers.
I have taken the approach of making the
DeliveryService
no-op if an appId is not supplied. There is probably some additional work that we could cancel (such as construction of payload messages etc), but I feel this is a good first approach. Perhaps ultimately we can aim to export as pure OTel & therefore kill a lot of SDK code.I would appreciate in-depth reviews on this as it substantially changes how the SDK works & I want to be sure I haven't forgotten anything important.