-
-
Notifications
You must be signed in to change notification settings - Fork 435
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
Add integration for Apollo-Kotlin 3 #2109
Conversation
…erialization with custom Deserlializer, support batched apollo requests
Codecov Report
@@ Coverage Diff @@
## main #2109 +/- ##
============================================
- Coverage 80.95% 80.91% -0.04%
- Complexity 3289 3313 +24
============================================
Files 233 236 +3
Lines 12048 12154 +106
Branches 1596 1615 +19
============================================
+ Hits 9753 9834 +81
- Misses 1712 1725 +13
- Partials 583 595 +12
Continue to review full report at Codecov.
|
buildSrc/src/main/java/Config.kt
Outdated
@@ -104,6 +104,8 @@ object Config { | |||
val graphQlJava = "com.graphql-java:graphql-java:17.3" | |||
|
|||
val kotlinReflect = "org.jetbrains.kotlin:kotlin-reflect" | |||
|
|||
val apollo3 = "com.apollographql.apollo3:apollo-runtime:3.3.0" |
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.
Should we call apolloKotlin
instead?
Apollo Kotlin (formerly known as Apollo Android) is a GraphQL client that generates Kotlin and Java models from GraphQL queries.
sentry-apollo-3/src/main/java/io/sentry/apollo3/SentryApollo3HttpInterceptor.kt
Outdated
Show resolved
Hide resolved
sentry-apollo-3/src/main/java/io/sentry/apollo3/SentryApollo3HttpInterceptor.kt
Outdated
Show resolved
Hide resolved
sentry-apollo-3/src/main/java/io/sentry/apollo3/SentryApollo3HttpInterceptor.kt
Outdated
Show resolved
Hide resolved
sentry-apollo-3/src/main/java/io/sentry/apollo3/SentryApollo3HttpInterceptor.kt
Outdated
Show resolved
Hide resolved
is ApolloNetworkException -> span.status = SpanStatus.INTERNAL_ERROR | ||
else -> SpanStatus.UNKNOWN |
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.
That looks wrong, every error would be UNKNOWN
if not thrown by network issues, the finally
block would be better cus there might be an error but at least we have a HTTP status code?
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.
Will double check but, afaik we get a httpResponse for all Status Codes including 4xx and 5xx in the HttpInterceptor
sentry-apollo-3/src/main/java/io/sentry/apollo3/SentryApollo3HttpInterceptor.kt
Outdated
Show resolved
Hide resolved
sentry-apollo-3/src/main/java/io/sentry/apollo3/SentryApollo3HttpInterceptor.kt
Outdated
Show resolved
Hide resolved
…o Builder api, update mockserver dependency
sentry-apollo-3/src/main/java/io/sentry/apollo3/SentryApollo3HttpInterceptor.kt
Outdated
Show resolved
Hide resolved
@@ -12,6 +12,7 @@ body: | |||
- sentry-jul | |||
- sentry-jdbc | |||
- sentry-apollo | |||
- sentry-apollo-3 |
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.
This requires adding the package in here https://github.com/getsentry/sentry-release-registry (for GA at least)
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.
Opened getsentry/sentry-release-registry#78
Needs changes to craft.yml still
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.
@marandaneto should I wait with adapting the craft.yml
until the release registry PR is approved?
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.
I'd comment it out, for now, getsentry/sentry-release-registry#78 isn't done yet and 6.2.0 is already outdated.
New approach:
Drawbacks:
|
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.
Nicely done 👏 only a few more things, otherwise LGTM.
sentry-apollo-3/src/main/java/io/sentry/apollo3/SentryApollo3HttpInterceptor.kt
Show resolved
Hide resolved
sentry-apollo-3/src/main/java/io/sentry/apollo3/SentryApollo3HttpInterceptor.kt
Outdated
Show resolved
Hide resolved
.addHeader(SentryApollo3HttpInterceptor.SENTRY_APOLLO_3_OPERATION_NAME, apolloRequest.operation.name()) | ||
|
||
apolloRequest.scalarAdapters?.let { | ||
builder.addHeader(SentryApollo3HttpInterceptor.SENTRY_APOLLO_3_VARIABLES, apolloRequest.operation.variables(it).valueMap.toString()) |
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.
Will this blow up if there's long variables? Do we need to truncate / skip if too long?
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.
Hmm, good point... Don't think it would blow up because header sizes are usually limited by the server side. However, in order to keep our request the Sentry Server small we should truncate/skip.
Is that something we could/should use SentryOptions#maxRequestBodySize
for?
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.
maxRequestBodySize
is about the body only, headers are added as it is, IIRC this should be guarded by defaultPii
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.
@marandaneto Actually these headers are meant to be passed internally only in order to work around the need to deserialize.
They are added by the SentryApollo3RequestComposer
and then read by the SentryApollo3HttpInterceptor
and then removed. Only if people use the RequestComposer
without the interceptor will the headers be sent over the wire. But then they don't get any use out of it as the Interceptor
is the one to send info to our Backend.
I think Alex's question was about size limits for headers in general.
As for my idea with the maxRequestBodySize
: Depending on the Apollo Operation the variables could get quite big and would therefore increase our payload sent to the Backend. Should we set a fixed sizeLimit or just send the variables as they are?
We thought about guarding with defaultPii
but decided against it, correct @adinauer ?
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.
I'd just send the variables as they are.
We don't do any trimming on the client, the server drops if it exceeds and reports to the client_reports
feature.
They can use the filtering callbacks to drop stuff in case they need to.
@lbloder using the request's header for this workaround could be problematic, in case this is a request for a 3rd party and somebody isn't using the interceptor, we can be leaking some PII data, I guess?
If there's no way around getting everything we need either with both interceptors, I'd rather go with the option that has more useful data and open an issue on the apollo3
repo with a feature request explaining our use case.
Maybe @bruno-garcia has opinions here.
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.
So, are we talking about sending the Request
and Headers
to our Backend?
Right now, we don't send the Request
or its Headers
to our Backend in the Interceptors
, neither are we doing this in e.g. SentryOkHttpInterceptor
nor in the SentryFeignClient
if I'm not mistaken. @marandaneto You said this is in our spec? Does this apply to mobile as well? Should we open issues for the other integrations as well?
If we do this, then Headers should most definitely be guarded behind PII imho.
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.
Right now, we don't send the Request or its Headers to our Backend in the Interceptors, neither are we doing this in e.g. SentryOkHttpInterceptor nor in the SentryFeignClient if I'm not mistaken. @marandaneto You said this is in our spec? Does this apply to mobile as well? Should we open issues for the other integrations as well?
Sorry, just found your original comment, so please ignore the above.
As for my workaround with using headers to pass data between Interceptors
, I don't see a problem if our headers are leaked, except that the request is getting bigger, because the headers we add only contain info that is in the request body anyways.
In terms of sending the whole request to the server, then I would definitely do it like in the SentryRequestResolver
that @adinauer linked
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.
If we are not sending headers in this PR to Sentry, no need to worry, but if we do, we should guard against defaultPii, See https://github.com/getsentry/sentry-dart/blob/d75a8c698a4942816336f3bae9a50c87fa6be0a8/dio/lib/src/dio_event_processor.dart#L117
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.
Made it easier to use with an extension function that adds both interceptors. Also this should make it harder to misconfigure,
The only headers we would send, and only if the SentryApollo3HttpInterceptor
isn't added, are those that contain variables
operationName
and operationType
which are all present in the request body anyways.
I would split sending the request
and its headers
to a separate issue for the integrations that are not sending those yet. I.e. The Apollo Integration v2 and v3, the OkHttp Integration, the FeignClient and maybe others, will look through them and create issues for those that are not sending the request
and its headers
to our backend.
Wdyt?
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.
We have #2148 to track.
sentry-apollo-3/src/test/java/io/sentry/apollo3/SentryApollo3InterceptorWithComposerTest.kt
Outdated
Show resolved
Hide resolved
…st, make return for beforeSpan nullable, add testcase for dropping spans, add baggage Headers to test
# Conflicts: # CHANGELOG.md # buildSrc/src/main/java/Config.kt
…ser and use interceptor, add extension function to apply both interceptors at once
fyi @marandaneto is OOO until the 20th, and @romtsn will be away for 60 days from the 20th. @adinauer might be able to help with reviews here or get a hold of folks internally. @philipphofmann might be able to chime in too |
Yes, I can help, but I'm pretty packed right now. If you need a review, please ping me on Discord, @lbloder. |
# Conflicts: # .craft.yml
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 thanks for doing this. Just need to wait for getsentry/sentry-release-registry#78 to be merged or comment out changes to .craft.yml
.
Instructions and example for changelogPlease add an entry to Example: ## Unreleased
- Add integration for Apollo-Kotlin 3 ([#2109](https://github.com/getsentry/sentry-java/pull/2109)) If none of the above apply, you can opt out of this check by adding |
📜 Description
Add tracing support for Apollo v3.
💡 Motivation and Context
Fixes #1850
💚 How did you test it?
📝 Checklist
🔮 Next steps