Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Updating Status based on the new spec #1313
Updating Status based on the new spec #1313
Changes from 2 commits
009d63e
74d8646
454fddc
bbb76e2
ce48282
7a01570
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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'm not an expert in what gRPC is doing, but this seems off to me. Just took a quick look at the code it seems to set a status code in grpc.status_code, then it sets status from that, and then it removes grpc.status_code. This new version, I feel like we are going to lose some fidelity that was there previously. Maybe we should set status as it is done here, but leave grpc.status_code set to the raw "canonicalcode" value? Maybe we should also move StatusCanonicalCode into gRPC library since it is no longer in line with the spec.
/cc @alanwest
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.
from this part, I'm still waiting a formal change in the spec to see.
I think I didn't change the part where it gets the value from the activity, so it might remain in the same way (the canonicalcode one). And, for the status itself, yeah, that will have only the 3 possibilities from spec.
Still waiting to confirm its behavior...
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 guess most likely the gRPC code will be stored in a similar fashion as
http.status_code
since it has more semantic than the Unset/Ok/Error value.I would suggest that we merge this PR as-is since the API part looks good, and we can catch the 0.7.0 release train.
The gRPC semantic convention is a lower priority comparing to the API since it is not a blocking issue, and it can be part of the 0.8.0 release or later.
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.
Right now, GRPC already fills the status in the tag as
grpc.status_code
. So, it won't be a problem at all 👍Yes, I think we can proceed and merge. Right now, the only part that is not "done" is the rpc part in the spec, since it will change because it was not updated in the first place.
Removing the label and adding to be merged asap
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.
grpc.status_code
is added by the library and the removal of the attribute in favor of the spec-approved attribute is intentional. See #1021.Are we adding back
grpc.status_code
until the spec change gets sorted out?I see a suggestion for something like
rpc.grpc.status_code
here open-telemetry/opentelemetry-specification#1044 (comment).I agree with @CodeBlanch that it will likely make sense to bring the
StatusCanonicalCode
into the gRPC instrumentation.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.
hi @alanwest , it would be strange to remove one tag and add another tag which contains the same value...i would just enable it and try to set that from spec side. for example, so we would need to just enable it in our side.
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.
(just updated the issue to maintain
grpc.status_code
. With that, we will just have to remove the SetTag => null for that key.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.
just enabled and i will create a new issue so we can follow the changes in the spec