Skip to content
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

[java] GraphQL Connected Services #2790

Closed
2 tasks
Tracked by #12
smeubank opened this issue Jun 19, 2023 · 1 comment · Fixed by #2856
Closed
2 tasks
Tracked by #12

[java] GraphQL Connected Services #2790

smeubank opened this issue Jun 19, 2023 · 1 comment · Fixed by #2856
Assignees

Comments

@smeubank
Copy link
Member

Background

We want to provide better GraphQL support with Sentry SDKs, frontend to backend. Work has already begun on some mobile platforms. There is also already some implementations for GraphQL server and client side. With the current work we want to ensure that the strategy to ensure proper connected errors and grouping works from backend to frontend. Java already has an integration for GraphQL.

Proposal

Java SDK should set context for GraphQL on errors same as what is done for Mobile SDK to ensure the value add from Frontend to Backend

Definition of Done TBC:

  • GraphQL Context
  • Propagating Trace

Further context:

getsentry/sentry#50230

@marandaneto
Copy link
Contributor

marandaneto commented Jun 19, 2023

https://github.com/getsentry/sentry-java/tree/main/sentry-apollo-3 already supports the captureFailedRequests feature (GraphQL Client errors).

TLDR:

  • Opt-in by default due to PII (requires request and response payload).
  • Set event.request.api_target to graphql
  • Populate the event.request including the data field (request payload)
  • Populate the event.contexts.response including the data field (response payload)
  • Set event.fingerprints to [$operationName, $operationType, $statusCode] (Only if stack traces are arbitrary, otherwise the default fingerprint is fine).
  • Set event.values.exception.mechanism.type so we can track adoption.
  • Propagating Trace (without performance)

Changes most likely here.
Just need to figure out how to enrich the event with the GraphQL context that is provided by the library, which data loader or resolver failed? the reason? etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

5 participants