-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
[translator/jaeger] For HTTP status codes in the 4xx range span status MUST be left unset in case of SpanKind.SERVER #12753
[translator/jaeger] For HTTP status codes in the 4xx range span status MUST be left unset in case of SpanKind.SERVER #12753
Conversation
00ac6e1
to
128b17c
Compare
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
mh.. i did like to reopen this pr. But it seems ive no permission to do so. could you help @jpkrohling ? |
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
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.
@frzifus thanks for the fix. could you please respond to the comments and rebase?
128b17c
to
7d182c9
Compare
ups seems my rebase messed things up... |
7d182c9
to
dc7a7b6
Compare
@frzifus it needs another rebase. Also please add a change log entry in |
// in case of SpanKind.SERVER and MUST be set to Error in case of SpanKind.CLIENT. | ||
// For HTTP status codes in the 5xx range, as well as any other code the client | ||
// failed to interpret, span status MUST be set to Error. | ||
if code, err := getStatusCodeFromHTTPStatusAttr(httpCodeAttr); span.Kind() == ptrace.SpanKindClient && err == nil { |
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 don't think it's correct logic here. Now we don't set error if span kind is server even for 5xx, but according to the spec we should, right? You can pass span kind to getStatusCodeFromHTTPStatusAttr
and use it as condition only for 4xx codes.
Please add a changelog entry |
attrs.Remove(tracetranslator.TagError) | ||
statusExists = true | ||
} | ||
attrs.Remove(tracetranslator.TagError) |
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.
We should not remove an attribute that has been explicitly added before us. Perhaps this is a 200 but an error occurred (the application might not be quite following REST principles).
The spec is a bit ambiguous here, as it states that it "must be left unset", but in this case, it was already set by something else (perhaps manually by developers? or using the attributes processor?).
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.
@jpkrohling So far we have been interchangeably treating jaeger error
tag and OTel StatusCode
in jaeger receiver/exporter with the exception that it worked only with error=true in the receiver due to the bug fixed in this PR. We set error
jaeger tag back from the OTel StatusCode
in the exporter
statusCodeTag, statusCodeTagFound = getTagFromStatusCode(status.Code()) |
error
tag as an additional OTel attribute, I believe it'll result into duplicated jaeger error
tag in the exporter. The correctness tests will also likely fail.
I'd suggest to keep the existing behavior and remove the tag but submit a separate issue where we discuss if it needs to be removed. PR to that issue would need to be applied to both receiver and exporter. WDYT?
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.
the changes got reverted.
tracetranslator.TagError: true, | ||
conventions.AttributeHTTPStatusCode: 404, | ||
}, | ||
status: errorStatus, |
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 must have read the code wrongly, as I would have expected this test to have failed. Given this test passes, the behavior is validated. The only other case that needs to be tested (in another PR perhaps?) is to set the error tag if the status code is greater than 500 and no error tag is set yet.
c922e9c
to
684f8ba
Compare
…n case of server kind Signed-off-by: Benedikt Bongartz <bongartz@klimlive.de>
Signed-off-by: Benedikt Bongartz <bongartz@klimlive.de>
684f8ba
to
0c992c1
Compare
Hi @dmitryax @jpkrohling, I have tried to address your comments. However, I am not sure if I have understood the conversions here correctly. Therefore, please review my changes carefully. 🙈. Would be very thankful for further feedback/guidance. |
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 believe this is correct now.
@dmitryax, would you like to take a final look, or can I merge it as is? |
…http codes (open-telemetry#12753) For HTTP status codes in the 4xx range span status MUST be left unset in case of SpanKind.SERVER Signed-off-by: Benedikt Bongartz <bongartz@klimlive.de>
Signed-off-by: Benedikt Bongartz bongartz@klimlive.de
Description:
This pr prevents the status code from being overwritten if the x error active is set to false.
Link to tracking Issue:
Testing:
Documentation: