Skip to content
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

fix(sdk-trace-base): avoid keeping non-string status.message on Span#setStatus() #4999

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

pichlermarc
Copy link
Member

@pichlermarc pichlermarc commented Sep 18, 2024

Which problem is this PR solving?

See #4998, Span#setStatus() is commonly used in catch blocks to set the span status SpanStatusCode.ERROR. While doing so, it's an easy mistake to make to also pass the Error as the message, which expects a string, as TypeScript will no complain as you assign any to string.

Therefore this PR adds a validation step to ensure we don't pass on the incorrect type downstream, which can cause OTLP/JSON export requests to be rejected.

Fixes #4998
See also renovatebot/renovate#31459

Type of change

  • Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

  • Added unit test

@pichlermarc pichlermarc marked this pull request as ready for review September 18, 2024 11:22
@pichlermarc pichlermarc requested a review from a team September 18, 2024 11:22
Copy link
Member

@dyladan dyladan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a comment but I'm not actually sure what the correct behavior should be. LMK what you think

Comment on lines +235 to +240
if (this.status.message != null && typeof status.message !== 'string') {
diag.warn(
`Dropping invalid status.message of type '${typeof status.message}', expected 'string'`
);
delete this.status.message;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is dropping the right behavior? If something is not nullish and also not a string, it may still be useful. Also, the user may be surprised to see nothing here. Maybe casting to string would be better?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been going back and forth on this as well - I've ended up with this approach as dropping it here gives us the opportunity to add casting as a string later as a feature.

I'm thinking that if we can get away with not doing any magic - then that's better. It will keep complexity lower, but also we discourage users from breaking the type-contract with the API.

@pichlermarc pichlermarc requested a review from a team September 19, 2024 10:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[sdk-trace] no type validation in places where it is common to pass caught Errors
2 participants