-
Notifications
You must be signed in to change notification settings - Fork 270
OpenTelemetry: Specify span kind and don't set error type for benign exception #2048
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| } | ||
| } | ||
|
|
||
| spanKind := trace.SpanKindServer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this line up roughly with what other SDKs like dotnet or python do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so (though I think I just spotted a bug in Python for outbound signal child workflow)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| } | ||
| } | ||
|
|
||
| spanKind := trace.SpanKindServer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so (though I think I just spotted a bug in Python for outbound signal child workflow)
|
|
||
| func (t *tracerSpan) Finish(opts *interceptor.TracerFinishSpanOptions) { | ||
| if opts.Error != nil { | ||
| if opts.Error != nil && !isBenignApplicationError(opts.Error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think our implementation may not have been doing the right thing here because we are not calling .RecordError, which I think we should always do on error regardless of whether benign (but status as error only for benign like you have here). I don't know if we consider now starting to record errors as a breaking/dangerous change, but probably not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the godoc of RecordError, I think you're right. This doesn't seem like a dangerous change, but kinda breaking? But I feel like something we probably want to do, to fix behavior
What was changed
serverfor inbound, andclientfor outboundToHeaderandFromHeader, they appear to directly be associated with if inbound or outboundWhy?
Checklist
Closes Set Span Kinds in Otel tracer interceptors #2024 and [Feature Request] Reclassify Benign Application errors in OpenTelemetry #2034
How was this tested:
Added tests
Note
Specify span kind (client/server) based on header direction, disallow both flags simultaneously, and only set error status for non-benign ApplicationErrors with accompanying tests.
trace.SpanKindClientwhenToHeaderis set; default totrace.SpanKindServer. Prevent bothToHeaderandFromHeaderfrom being set. Passtrace.WithSpanKindinto span start.RecordError; set status tocodes.Erroronly if the error is not a benigntemporal.ApplicationError(helperisBenignApplicationError).TestSpanKindandTestBenignErrorSpanStatusto validate span kind selection and benign error status behavior.Written by Cursor Bugbot for commit 101db75. This will update automatically on new commits. Configure here.