WIP feat(opentelemetry): Add SentryTraceProvider#21181
Conversation
size-limit report 📦
|
0f2020a to
71e7c69
Compare
| */ | ||
| public recordException(_exception: unknown, _time?: number | undefined): void { | ||
| // noop | ||
| public recordException(exception: unknown, time?: SpanTimeInput | undefined): void { |
There was a problem hiding this comment.
I think we can leave this as noop, we do not care about this and do not really support it, doing nothing with events etc.
71e7c69 to
a44215e
Compare
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 a44215e. Configure here.
|
|
||
| if (typeof grpcCodeAttribute === 'string') { | ||
| return { code: SPAN_STATUS_ERROR, message: GRPC_STATUS_CODE_MAP[grpcCodeAttribute] || 'unknown_error' }; | ||
| } |
There was a problem hiding this comment.
gRPC numeric status codes silently ignored in status inference
Medium Severity
inferOtelSpanStatusFromAttributes only checks typeof grpcCodeAttribute === 'string', but the OTel semantic convention defines rpc.grpc.status_code as an integer. Numeric gRPC error codes (the common case from instrumentation libraries) fall through to undefined, causing the caller to default to SPAN_STATUS_OK — even for actual gRPC errors like UNKNOWN (2) or INTERNAL (13). Additionally, a string '0' (gRPC OK) would incorrectly map to SPAN_STATUS_ERROR since GRPC_STATUS_CODE_MAP has no entry for '0', yielding 'unknown_error'. The HTTP code path correctly handles both number and string types; the gRPC path needs the same treatment plus a guard for code 0.
Reviewed by Cursor Bugbot for commit a44215e. Configure here.


WIP