Conversation
Semver Impact of This PR🟡 Minor (new features) 📋 Changelog PreviewThis is how your changes will appear in the changelog. New Features ✨
Bug Fixes 🐛
Internal Changes 🔧Ai
Other
🤖 This preview updates automatically when you update the PR. |
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Autofix Details
Bugbot Autofix prepared a fix for the issue found in the latest run.
- ✅ Fixed: Event processor overwrites entire trace context losing fields
- The event processor now updates
trace_idandspan_idin the existingevent.Contexts["trace"]map (creating it only when absent), preserving SDK-populated trace fields.
- The event processor now updates
Or push these changes by commenting:
@cursor push 38eedc31b4
Preview (38eedc31b4)
diff --git a/otel/internal/common/event_processor.go b/otel/internal/common/event_processor.go
--- a/otel/internal/common/event_processor.go
+++ b/otel/internal/common/event_processor.go
@@ -27,9 +27,12 @@
if event.Contexts == nil {
event.Contexts = make(map[string]map[string]any)
}
- event.Contexts["trace"] = map[string]any{
- "trace_id": otelSpanContext.TraceID().String(),
- "span_id": otelSpanContext.SpanID().String(),
+ traceContext, found := event.Contexts["trace"]
+ if !found || traceContext == nil {
+ traceContext = make(map[string]any)
+ event.Contexts["trace"] = traceContext
}
+ traceContext["trace_id"] = otelSpanContext.TraceID().String()
+ traceContext["span_id"] = otelSpanContext.SpanID().String()
return event
}
diff --git a/otel/internal/common/event_processor_test.go b/otel/internal/common/event_processor_test.go
--- a/otel/internal/common/event_processor_test.go
+++ b/otel/internal/common/event_processor_test.go
@@ -22,7 +22,7 @@
{name: "without existing trace context"},
{
name: "with existing trace context",
- existingTrace: map[string]any{"trace_id": "123", "parent_span_id": "456"},
+ existingTrace: map[string]any{"trace_id": "123", "parent_span_id": "456", "op": "http.server"},
},
}
@@ -43,10 +43,12 @@
}))
got := linkTraceContextToErrorEvent(event, &sentry.EventHint{Context: ctx})
- assert.Equal(t, map[string]any{
- "trace_id": traceID.String(),
- "span_id": spanID.String(),
- }, got.Contexts["trace"])
+ assert.Equal(t, traceID.String(), got.Contexts["trace"]["trace_id"])
+ assert.Equal(t, spanID.String(), got.Contexts["trace"]["span_id"])
+ if tt.existingTrace != nil {
+ assert.Equal(t, "456", got.Contexts["trace"]["parent_span_id"])
+ assert.Equal(t, "http.server", got.Contexts["trace"]["op"])
+ }
})
}
}This Bugbot Autofix run was free. To enable autofix for future PRs, go to the Cursor dashboard.
| func (errorLinkingIntegration) Name() string { | ||
| return "OtelErrorLinking" | ||
| } |
There was a problem hiding this comment.
Bug: Initializing multiple Sentry clients with NewErrorLinkingIntegration() registers the same global event processor multiple times, causing redundant event processing and performance overhead.
Severity: MEDIUM
Suggested Fix
To prevent duplicate registration, the SetupOnce method should be made idempotent. This can be achieved by using a global flag, such as a sync.Once or a boolean, to ensure that sentry.AddGlobalEventProcessor() is only called the first time SetupOnce is executed across all client initializations.
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: otel/error_linking.go#L17-L19
Potential issue: When multiple Sentry clients are initialized with
`NewErrorLinkingIntegration()`, the integration's `SetupOnce` method is called for each
client. This method unconditionally calls `sentry.AddGlobalEventProcessor()`, appending
the same processor to the global `globalEventProcessors` slice multiple times. Because
the check for installed integrations is per-client, not global, this duplication is not
prevented. As a result, every event is processed redundantly by each registered instance
of the processor, leading to unnecessary performance overhead.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
|
|
||
| func (errorLinkingIntegration) SetupOnce(_ *sentry.Client) { | ||
| sentry.AddGlobalEventProcessor(common.NewEventProcessor()) | ||
| } |
There was a problem hiding this comment.
Integration uses global processor instead of per-client processor
Medium Severity
errorLinkingIntegration.SetupOnce calls sentry.AddGlobalEventProcessor instead of using the provided *sentry.Client parameter (which is discarded with _). The established convention for Sentry integrations (e.g. modulesIntegration) is to use client.AddEventProcessor. Because SetupOnce is called on every sentry.Init, each initialization appends another copy of the processor to the global list, causing it to run multiple times per event. Using client.AddEventProcessor would scope the processor to the specific client and prevent unbounded accumulation.
1 participant
Description
This PR adds the OpenTelemetry integration for OTLP, while also separating the error linking from the span exporter. The PR also includes some deviations from the Spec, so that the package follows closely the OTel conventions.
The main changes:
sentryotel.NewErrorLinkingIntegration()for OTel users to link errors with traces.sentryotlppackage where users can create aNewTraceExporterto send to sentry's otlp endpoint using theotlptracehttpexporter.Deviations from the spec:
setup_otlp_traces_exporterflag since users need to manually provide the exporter to theTracerProvidercollector_url. For users that are already using the collector, the only thing they need to set up is theErrorLinkingIntegration. Having aWithCollectorURLoption mixes concerns, since thesentryotlptrace exporter should only forward to sentry. Using the collector with Sentry requires changing the otlp http configuration on the collector and not the integration level.Issues
Changelog Entry Instructions
To add a custom changelog entry, uncomment the section above. Supports:
For more details: custom changelog entries
Reminders
feat:,fix:,ref:,meta:)