Skip to content

feat(core): Add and use dataCollection.graphQL#22221

Merged
s1gr1d merged 3 commits into
developfrom
sig/add-dataCollection-graphQL
Jul 14, 2026
Merged

feat(core): Add and use dataCollection.graphQL#22221
s1gr1d merged 3 commits into
developfrom
sig/add-dataCollection-graphQL

Conversation

@s1gr1d

@s1gr1d s1gr1d commented Jul 13, 2026

Copy link
Copy Markdown
Member

Sets the default collection behavior to true as it has been collected already.

@s1gr1d s1gr1d requested review from a team as code owners July 13, 2026 10:50
@s1gr1d s1gr1d requested review from Lms24, andreiborza, chargome, isaacs, logaretm, mydea and nicohrubec and removed request for a team July 13, 2026 10:50
Comment on lines +59 to +62
graphQL?: {
document?: boolean;
variables?: boolean;
};

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: The graphQL.variables configuration option is defined but never used, making the feature to control GraphQL variable collection non-functional.
Severity: HIGH

Suggested Fix

Implement the logic to read the getDataCollectionOptions().graphQL.variables setting. Based on its value, conditionally collect or suppress the variables field from GraphQL requests. This logic should be added where GraphQL bodies are processed, such as in packages/browser/src/integrations/graphqlClient.ts and packages/server-utils/src/graphql/utils.ts.

Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: packages/core/src/types/datacollection.ts#L59-L62

Potential issue: The `graphQL.variables` configuration option is defined and documented,
but its value is never read in the production codebase. No code checks
`getDataCollectionOptions().graphQL.variables` before collecting GraphQL variables.
Since no variable collection code exists, the setting has no effect. Users who set
`graphQL: { variables: false }` believing they are suppressing variable collection are
not actually having variables collected (as the feature is missing), and users who set
`variables: true` believing variables will be captured find they are not. The API
contract is unfulfilled as the implementation is missing.

Did we get this right? 👍 / 👎 to inform future reviews.

@github-actions

github-actions Bot commented Jul 13, 2026

Copy link
Copy Markdown
Contributor

size-limit report 📦

Path Size % Change Change
@sentry/browser 27.65 kB +0.15% +40 B 🔺
@sentry/browser - with treeshaking flags 26.1 kB +0.19% +48 B 🔺
@sentry/browser (incl. Tracing) 46.42 kB +0.13% +56 B 🔺
@sentry/browser (incl. Tracing + Span Streaming) 48.21 kB +0.11% +51 B 🔺
@sentry/browser (incl. Tracing, Profiling) 51.2 kB +0.11% +52 B 🔺
@sentry/browser (incl. Tracing, Replay) 85.67 kB +0.05% +39 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags 75.31 kB +0.06% +44 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas) 90.38 kB +0.05% +42 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback) 103.04 kB +0.04% +40 B 🔺
@sentry/browser (incl. Feedback) 44.83 kB +0.11% +46 B 🔺
@sentry/browser (incl. sendFeedback) 32.45 kB +0.14% +44 B 🔺
@sentry/browser (incl. FeedbackAsync) 37.58 kB +0.12% +44 B 🔺
@sentry/browser (incl. Metrics) 28.74 kB +0.18% +50 B 🔺
@sentry/browser (incl. Logs) 28.98 kB +0.15% +42 B 🔺
@sentry/browser (incl. Metrics & Logs) 29.67 kB +0.16% +47 B 🔺
@sentry/react 29.45 kB +0.18% +50 B 🔺
@sentry/react (incl. Tracing) 48.68 kB +0.1% +46 B 🔺
@sentry/vue 33.08 kB +0.14% +44 B 🔺
@sentry/vue (incl. Tracing) 48.4 kB +0.13% +59 B 🔺
@sentry/svelte 27.67 kB +0.15% +40 B 🔺
CDN Bundle 30.05 kB +0.16% +47 B 🔺
CDN Bundle (incl. Tracing) 48.41 kB +0.14% +64 B 🔺
CDN Bundle (incl. Logs, Metrics) 31.64 kB +0.16% +49 B 🔺
CDN Bundle (incl. Tracing, Logs, Metrics) 49.71 kB +0.11% +53 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics) 70.87 kB +0.07% +43 B 🔺
CDN Bundle (incl. Tracing, Replay) 85.9 kB +0.07% +56 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics) 87.21 kB +0.06% +49 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) 91.7 kB +0.06% +49 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) 92.97 kB +0.05% +45 B 🔺
CDN Bundle - uncompressed 89.58 kB +0.25% +216 B 🔺
CDN Bundle (incl. Tracing) - uncompressed 146.33 kB +0.15% +216 B 🔺
CDN Bundle (incl. Logs, Metrics) - uncompressed 94.29 kB +0.23% +216 B 🔺
CDN Bundle (incl. Tracing, Logs, Metrics) - uncompressed 150.31 kB +0.15% +216 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics) - uncompressed 219.02 kB +0.1% +216 B 🔺
CDN Bundle (incl. Tracing, Replay) - uncompressed 265.54 kB +0.09% +216 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics) - uncompressed 269.5 kB +0.09% +216 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed 279.24 kB +0.08% +216 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) - uncompressed 283.19 kB +0.08% +216 B 🔺
@sentry/nextjs (client) 51.22 kB +0.09% +46 B 🔺
@sentry/sveltekit (client) 46.86 kB +0.13% +57 B 🔺
@sentry/core/server 78.47 kB +0.07% +53 B 🔺
@sentry/core/browser 64.82 kB +0.08% +50 B 🔺
@sentry/node-core 62.79 kB +0.11% +65 B 🔺
@sentry/node 125.2 kB +0.09% +111 B 🔺
@sentry/node (incl. diagnostics channel injection) 139.76 kB +0.08% +100 B 🔺
@sentry/node/import (ESM hook with diagnostics-channel injection) 69.96 kB - -
@sentry/node/light 50.8 kB +0.14% +67 B 🔺
@sentry/node - without tracing 74.17 kB +0.1% +71 B 🔺
@sentry/aws-serverless 83.39 kB +0.08% +60 B 🔺
@sentry/cloudflare (withSentry) - minified 181.79 kB +0.12% +216 B 🔺
@sentry/cloudflare (withSentry) 449.98 kB +0.11% +490 B 🔺

View base workflow run

Comment on lines +59 to +62
graphQL?: {
document?: boolean;
variables?: boolean;
};

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a blocker but something I was discussing with @ericapisani, this creates the expectation that the SDK is going to apply these options to all GraphQL requests which is not accurate.

It would only apply if the user is using the client or the server GraphQL integrations. GraphQL requests outside of the integrations coverage won't be covered by these options which I find weird. I know the gen AI spans is already a precedent, so I don't have strong opinions here.

An alternative I considered is adding the dataCollection option to the integrations themselves rather than a top-level option.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The core idea of the top-level option is to have only one place where all of this is defined in an on/off switch manner (like: this is allowed to be sent, but you also need the integration to be enabled). This makes it easier to see it all at once. According to the spec, it's also possible to add it on integration level, which would overwrite the option set on the root-level.

Maybe we should make this more clear in the JSDoc?

@logaretm logaretm Jul 13, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's fine, we already have a precedent for it with gen AI stuff so not feeling too strongly about it but it is something that I wanted to bring up is all.

Maybe adding a line or two in the JS doc to explain what "it won't do" will help here.

@s1gr1d s1gr1d enabled auto-merge (squash) July 14, 2026 07:48
Comment on lines +30 to +32
// The GraphQL document has literal values redacted at collection time, so it was historically
// always attached regardless of `sendDefaultPii`; keep it on to preserve that behavior.
graphQL: { document: true, variables: true },

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: When sendDefaultPii is false, graphQL.variables is incorrectly set to true. This contradicts the goal of minimizing PII collection and sets up a potential future PII leak.
Severity: HIGH

Suggested Fix

Change the default setting for graphQL.variables to false when sendDefaultPii is false in defaultPiiToCollectionOptions.ts. This aligns the behavior with other PII-sensitive settings and prevents a future potential PII leak. The line should be changed to graphQL: { document: true, variables: false }.

Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location:
packages/core/src/utils/data-collection/defaultPiiToCollectionOptions.ts#L30-L32

Potential issue: The default data collection options set `graphQL.variables` to `true`
even when `sendDefaultPii` is `false`. The purpose of `sendDefaultPii: false` is to
prevent the collection of Personally Identifiable Information (PII). GraphQL variables
can contain sensitive user data, and unlike `graphQL.document`, they are not redacted.
While no code currently consumes the `graphQL.variables` setting, this configuration is
a design error. It creates a high risk that future code implementing GraphQL variable
collection will inadvertently capture and send PII for users who have opted out, as the
default setting will be assumed to be safe.

@s1gr1d s1gr1d merged commit f14b258 into develop Jul 14, 2026
311 checks passed
@s1gr1d s1gr1d deleted the sig/add-dataCollection-graphQL branch July 14, 2026 08:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants