feat: add trace methods to public API - #1394
Conversation
4d788fd to
deeab0c
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
This adds trace, logging and metrics primitives so that integrations can be cleanly migrated to scopes and context.
deeab0c to
7e6baff
Compare
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| if client.captureMetric(metric, signalCaptureContext{scope: scope, ctx: ctx}) && client.options.Debug { | ||
| debuglog.Printf("Metric %s [%s]: %v %s", metricType, name, value.AsInterface(), unit) | ||
| } | ||
| } | ||
|
|
||
| func prepareMetric(metric *Metric, client *Client, capture signalCaptureContext) { | ||
| trace := resolveTrace(capture.scope, client, capture.ctx, capture.fallback) | ||
| trace := resolveTrace(capture.scope, client, capture.ctx) | ||
| metric.TraceID = trace.traceID |
There was a problem hiding this comment.
Bug: Removing the fallback to the creation-time context can cause trace information to be lost if metrics are emitted with a context lacking the original trace data.
Severity: MEDIUM
Suggested Fix
Restore the previous behavior by using the creation-time context as a fallback. Utilize a mechanism similar to the previous hubFromContexts(ctx, m.ctx) to ensure that if the emit-time ctx lacks a scope, the scope from the creation-time context is used to preserve trace information.
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: metrics.go#L120-L127
Potential issue: The removal of a fallback to the creation-time context can lead to the
silent loss of trace information. The new code determines the Sentry scope exclusively
from the emit-time context using `scope = ScopeFromContext(ctx)`. If this context lacks
a Sentry scope, `scope` becomes `nil`, and the `resolveTrace` function returns a zeroed
`traceResolution`, dropping all trace IDs. The previous implementation avoided this by
using the creation-time context as a fallback (`hubFromContexts(ctx, m.ctx)`), which
preserved trace data even if the emit-time context was bare.
Did we get this right? 👍 / 👎 to inform future reviews.
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.
Reviewed by Cursor Bugbot for commit 7e6baff. Configure here.
|
|
||
| // NewLogger returns a Logger that emits logs to Sentry. | ||
| func NewLogger(ctx context.Context) Logger { // nolint: dupl | ||
| var hub *Hub |
There was a problem hiding this comment.
Client lookup skips hub-bound clients
High Severity
NewLogger and NewMeter now resolve the client only through GetClient, which checks a context scope or GlobalScope. A client bound with CurrentHub().BindClient is no longer found unless Init also set GlobalScope or the context carries a scope. Logs and metrics are silently discarded, and scope data from ConfigureScope is dropped.
Additional Locations (2)
Reviewed by Cursor Bugbot for commit 7e6baff. Configure here.
1 participant
Description
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:)