Conversation
`forceTransaction` no longer has a concrete use case: all spans are indexed and searchable in Sentry, so a span does not need to be a transaction to be queried, filtered or aggregated on. The option will be removed in the next major version. For the remaining cases where a span genuinely has to be a segment (root) span, the JSDoc points to starting it without a parent span (`withActiveSpan(null, ...)`, optionally inside `continueTrace`) instead of forcing it into a transaction. Internal SDK usages are suppressed with an oxlint directive for now and will be evaluated separately. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`op` duplicates the `sentry.op` span attribute, which is the canonical way to categorize a span. It will be removed in a future version; the deprecation deliberately does not name a specific one. All internal usages are rewritten to set `sentry.op` (via the `SENTRY_OP` constant from `@sentry/conventions`) instead. Precedence is unchanged everywhere: an explicit `sentry.op` attribute still wins over `op`. Call sites that already set both now only set the attribute. `browserTracingIntegration` is the one exception that still touches `op`: `beforeStartSpan` is a public hook that receives and may override it, so the option is kept in the options handed to the hook and only folded into `sentry.op` afterwards. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
| // oxlint-disable-next-line typescript/no-deprecated | ||
| if (finalStartSpanOptions.op !== originalOp) { | ||
| // oxlint-disable-next-line typescript/no-deprecated | ||
| attributes[SENTRY_OP] = finalStartSpanOptions.op; | ||
| } |
There was a problem hiding this comment.
Bug: If a beforeStartSpan callback returns an options object without the op field, the span's operation (SENTRY_OP) attribute is incorrectly deleted, breaking UI categorization.
Severity: HIGH
Suggested Fix
Modify the condition to ensure finalStartSpanOptions.op is defined before comparing it to originalOp. For example: if (finalStartSpanOptions.op !== undefined && finalStartSpanOptions.op !== originalOp).
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/browser/src/tracing/browserTracingIntegration.ts#L354-L358
Potential issue: When a `beforeStartSpan` callback returns a new options object that
omits the deprecated `op` field, the check `finalStartSpanOptions.op !== originalOp`
incorrectly evaluates to `true` because `finalStartSpanOptions.op` is `undefined`. This
leads to `attributes[SENTRY_OP]` being set to `undefined`. Subsequently, when
`SentrySpan.setAttribute` is called with an `undefined` value, it deletes the
`SENTRY_OP` key from the span's attributes. This causes pageload and navigation spans to
lose their operation type, which breaks filtering and categorization in the Sentry UI.
This is triggered by a common usage pattern recommended in documentation.
Did we get this right? 👍 / 👎 to inform future reviews.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 2fa39b2. Configure here.
| * }), | ||
| * ), | ||
| * ); | ||
| * ``` |
There was a problem hiding this comment.
Feat PR lacks integration tests
Low Severity
Flagged because the review rules require feat PRs to include at least one integration or E2E test. This change deprecates op and forceTransaction and migrates route span creation to sentry.op, but the diff only updates existing unit tests.
Triggered by project rule: PR Review Guidelines for Cursor Bot
Reviewed by Cursor Bugbot for commit 2fa39b2. Configure here.


This PR:
forceTransactionStartSpanOptionspropertySentry.continueTrace(Sentry.withActiveSpan(null, Sentry.startSpan())). Not a pretty workaround but based on feedback and needs, we can evaluate adding a helper or a newforceSegment(naming TBD) optionforceTransactionStartSpanOptionspropertysentry.opattribute which is straight forwardopusages were replacedbeforeSendSpancallback adjusted to backfill top-levelopfromsentry.opattribute