-
-
Notifications
You must be signed in to change notification settings - Fork 348
feat: Send GraphQL "operationName" in HTTP breadcrumbs #3931
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
feat: Send GraphQL "operationName" in HTTP breadcrumbs #3931
Conversation
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.
Hello @maxchuquimia. Thank you so much for the help.
The PR looks very good, with tests and all.
I left a comment of something that needs changing.
The PR is also missing a CHANGELOG entry.
Nice work!!
@brustolin updated! |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3931 +/- ##
=============================================
- Coverage 90.767% 90.727% -0.040%
=============================================
Files 586 588 +2
Lines 45783 45879 +96
Branches 16326 16356 +30
=============================================
+ Hits 41556 41625 +69
- Misses 4047 4183 +136
+ Partials 180 71 -109
... and 38 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
This looks good to me. @philipphofmann, @kahest thoughts? |
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.
Thanks a lot for this PR. I think we only need a couple of improvements then we can merge this. Most important we should align with how we add GraphQL breadcrumbs in our Java SDK, see also our develop docs. If you can't easily retrieve operation_name
, operation_type
and operation_id
, it's also acceptable to only do operation_name
.
- Rewrite operation name extraction in Swift - Rename graphql to operation_name in breadcrumb - Add further tests for operation name extraction - Add missing options test
Hey @philipphofmann, cheers for your comments! I have made the following changes:
|
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.
Two minor things to fix. Then we can merge this. Thank you @maxchuquimia 👍
@philipphofmann Done! 🎉 |
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, thank you @maxchuquimia 🥇 .
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
Hey @brustolin, you mentioned "We can't use Objc Categories to extend a class" -- as part of later comments I was asked to migrate the code in this PR to Swift, does this rule apply to Swift Extensions somehow? Now that this has been merged we are attempting to use it but are receiving this crash, I'm not sure how the function could not be there seeing as it compiled just fine 😅
|
Hmm, it could be that Swift extension methods don't work. @maxchuquimia, can you try to convert the getGraphQLOperationName to a helper function that takes |
PR opened @philipphofmann - #3973 |
Resolved a crash introduced with #3931. Co-authored-by: Max Chuquimia <> Co-authored-by: Philipp Hofmann <philipp.hofmann@sentry.io>
This PR attempts to support sending GraphQL operation names with existing HTTP breadcrumbs. Co-authored-by: Max Chuquimia <> Co-authored-by: Philipp Hofmann <philipp.hofmann@sentry.io>
📜 Description
This PR attempts to support sending GraphQL operation names with existing HTTP breadcrumbs.
💡 Motivation and Context
When using GraphQL requests, Sentry's HTTP breadcrumbs are not valuable as they all show the same URL. Being able to see the operation name in a HTTP breadcrumb is extremely useful when tracking down what happened leading up to an error.
The main reason I am opening this PR now is because of Sentry's move to distributing XCFrameworks. This has made my fork unusable as pointing our app's
Package.swift
to our fork doesn't immediately change the downloaded.binaryTarget
in Sentry'sPackage.swift
. At a glance, the GitHub Actions in my fork are failing so I thought opening a PR may be the easiest option to enable us to update Sentry (which we now need to do to getPrivacyInfo.xcprivacy
).Relates to #3494
💚 How did you test it?
📝 Checklist
You have to check all boxes before merging:
sendDefaultPII
is enabled.🔮 Next steps