Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 12 additions & 2 deletions develop-docs/sdk/foundations/client/data-collection/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -2,12 +2,15 @@
title: Data Collection
description: Configuration for what data SDKs collect by default, including technical context, PII, and sensitive data.
spec_id: sdk/foundations/client/data-collection
spec_version: 0.5.0
spec_version: 0.6.0
spec_status: candidate
spec_depends_on:
- id: sdk/foundations/client
version: ">=1.0.0"
spec_changelog:
- version: 0.6.0
date: 2026-06-29
summary: Include configuration for database queries.
- version: 0.5.0
date: 2026-06-26
summary: Include configuration options for controlling the inclusion of graphql documents and variables.
Expand Down Expand Up @@ -73,7 +76,7 @@ Personally Identifiable Information (PII) or user-linked data. Examples include,
- Contact (email, phone number, address)
- IP address
- Cookies and headers that identify the user or session
- HTTP request data (TBD)
- HTTP request data or database query parameters (TBD)

For context types that may carry PII fields (e.g. `device_unique_identifier` in [Device Context](/sdk/foundations/transport/event-payloads/contexts/#device-context), or fields in the [User Interface](/sdk/foundations/transport/event-payloads/user/)), see the linked specs.

Expand Down Expand Up @@ -537,6 +540,9 @@ init({
inputs?: boolean, // default: true
outputs?: boolean, // default: true
},
database?: {
queryParams?: boolean // default: true
},
stackFrameVariables?: boolean, // default: true
frameContextLines?: integer, // default: 5 (see boolean fallback below)
},
Expand All @@ -552,6 +558,7 @@ init({
| `queryParams` | Key-value collection | `{ mode: "denyList" }` | 0.1.0 | Collect URL query parameters. All key names are always included; the SDK scrubs values for keys matching the sensitive denylist or custom allow/deny terms. |
| `graphql` | `{ document?, variables? }` | Both `true` | 0.5.0 | For `document`: Collect the GraphQL document. <br /><br /> For `variables`: Collect the variables that are passed to GraphQL operations. |
| `genAI` | `{ inputs?, outputs? }` | Both `true` | 0.1.0 | For `inputs`: Include the content of generative AI inputs (e.g. prompt text, tool call arguments). <br /><br /> For `outputs`: Include the content of generative AI outputs (e.g. completion text, tool call results). Metadata such as model name and token counts is always collected regardless of these settings. |
| `database` | `{ queryParams? }` | `true` | 0.6.0 | Include parameters/arguments passed to database queries. Setting this to false will either omit the value altogether, or replace the value with '[Filtered]'. |

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 default value for the database option is documented as true, which is inconsistent and ambiguous compared to other nested options like graphql.
Severity: LOW

Suggested Fix

Update the default value column for the database option to be consistent with other nested options. For example, change true to queryParams: true to clarify the default applies to the nested field. Also, clarify the description to explicitly mention queryParams.

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: develop-docs/sdk/foundations/client/data-collection/index.mdx#L561

Potential issue: In the options table, the `database` option's default value is
documented as `true`. This is ambiguous and inconsistent with how similar nested options
like `graphql` and `genAI` are documented, which use `Both true` to clarify that their
nested properties default to `true`. This could lead SDK implementors to misinterpret
the API. The accompanying description, "Setting this to false...", is also unclear about
whether "this" refers to the parent `database` object or the nested `queryParams` field.
While the pseudocode section is correct, the table should be self-consistent to avoid
confusion.

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

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.

Boolean false behavior contradicts spec

Medium Severity

The new database option description says queryParams: false may omit values or replace them with [Filtered], but the Boolean Options section defines false as not collecting the category at all. SDKs can implement incompatible opt-out behavior for the same setting.

Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit d1e4b2b. Configure here.

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 description for database.queryParams when false is ambiguous, stating it could either omit the value or replace it with '[Filtered]', contradicting the spec's definition for boolean options.
Severity: MEDIUM

Suggested Fix

Update the description for database.queryParams when set to false to align with the standard behavior for boolean options. It should clearly state that setting it to false means the data category will not be collected, removing the 'either omit... or replace' ambiguity.

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: develop-docs/sdk/foundations/client/data-collection/index.mdx#L561

Potential issue: The documentation for `database.queryParams` provides an ambiguous
definition for when the option is set to `false`. It states the value will be 'either
omit the value altogether, or replace the value with '[Filtered]''. This conflicts with
the general specification for boolean options, which dictates that `false` should mean
'Do not collect this data category'. This ambiguity could lead to different SDKs
implementing the feature inconsistently, defeating the purpose of a unified
specification.

| `stackFrameVariables` | Boolean | `true` | 0.1.0 | Include local variable values captured within stack frames. |
| `frameContextLines` | Integer (`Boolean` fallback) | `5` (`true`) | 0.1.0 | Number of source code lines to include above and below each stack frame. <br/> **`Boolean` fallback:** Not all platforms support integer configuration values. SDKs **MAY** accept a boolean, where `true` is equivalent to the platform default (typically `5`) and `false` is equivalent to `0` (no context lines). SDKs **SHOULD** prefer accepting an integer when their platform supports it. |

Expand Down Expand Up @@ -655,6 +662,9 @@ init({
inputs: false,
outputs: false,
},
database: {
queryParams: false,
},
Comment on lines +665 to +667

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.

If we add this, this should also be a required part of the commented out docs/on-boarding snippet. We should add a section to this page for this, currently it's userInfo, httpBodies and now this.

For naming, databaseQueryParams might be better, not sure we need the namespace.

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.

For naming, databaseQueryParams might be better, not sure we need the namespace.

I considered something like this but opted for the dict to make it easier to extend in the future should we need to for whatever reason - I didn't want to take the chance and require us to introduce an unnecessary breaking change if something needed to e added when we could've done this at the beginning.

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.

@cleptric could you give me some more clarification on which sections you're referring to in:

If we add this, this should also be a required part of the commented out docs/on-boarding snippet.

The database setting has been added the example code snippets already, and in terms of other potential sections - there's a couple possible ones that I think you're referring to and I want to make sure I'm not missing anything/updating the right spots. The ones that I think you're referring to are:

  • Setup Snippet Opt-out Comment (include database option)
  • Creating a new section alongside the "Request and Response Bodies", "Cookies and Query Params", etc. that explains what's captured by the database setting.

Is there anything else?

httpHeaders: { deny: ["forwarded", "-ip", "remote-", "via", "-user"] },
cookies: { deny: ["forwarded", "-ip", "remote-", "via", "-user"] },
queryParams: { deny: ["forwarded", "-ip", "remote-", "via", "-user"] },
Expand Down
Loading