Meaningful message when span name is not a string #3955
Conversation
| logger.warning( | ||
| "span name must be a string.\n Stack trace: %s", stack_trace | ||
| ) | ||
| name = str(name) |
There was a problem hiding this comment.
Did you consider cases where converting the name to a string might fail?
There was a problem hiding this comment.
I cannot really think of any case where this could fail. Did you have any such cases in mind?
There was a problem hiding this comment.
It's good that we're logging something, but I'm not sure that we want to log a stack trace here. Is logging a stacktrace done elsewhere in this repo?
Regarding testing, I think we should test passing in a string, and test passing in a non-string, making sure both scenarios produce expected results.
There was a problem hiding this comment.
I don't see logging a stacktrace being done anywhere in the repo. Would you like me to change it and if so, how would you like me to change it?
Sure, working on it now.
There was a problem hiding this comment.
Maybe this should just raise a TypeError. Anybody have thoughts?
if not isinstance(name, str):
raise TypeError(f"Expected 'name' to be a string, but got {type(name).__name__}")
There was a problem hiding this comment.
@pmcollins, and in that case, we don't try to convert to str, right?
I was wondering about this:
API methods MUST NOT throw unhandled exceptions when used incorrectly by end users. The API and SDK SHOULD provide safe defaults for missing or invalid arguments. For instance, a name like empty may be used if the user passes in null as the span name argument during Span construction.
I didn't find a clarification on what is a valid span name other than this:
The span name SHOULD be the most general string that identifies a (statistically) interesting class of Spans rather than individual Span instances while still being human-readable. That is, "get_user" is a reasonable name, while "get_user/314159", where "314159" is a user ID, is not a good name due to its high cardinality. Generality SHOULD be prioritized over human-readability.
There was a problem hiding this comment.
Yes, good point, the exception would have to be handled. And in this case there are two call sites, so perhaps it's better to handle it here in the end.
There was a problem hiding this comment.
Sure, will do that. Also, should I just raise a TypeError as you stated before or should I convert it to a string and continue execution like it is now?
There was a problem hiding this comment.
I think we shouldn't convert to str and we must also be careful not to generate excessive warnings. I would suggest you bring this to next SIG call and get some opinions
Description
When the span name is not a string, the error message is confusing. Logs a warning message "span name must be a string" with the stack trace to help identify where the issue is. Converts the span name to a string and continues execution.
Fixes #3918
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
Ran the code given in the issue to reproduce the issue.
Does This PR Require a Contrib Repo Change?
Answer the following question based on these examples of changes that would require a Contrib Repo Change:
The OTel specification has changed which prompted this PR to update the method interfaces of
opentelemetry-api/oropentelemetry-sdk/The method interfaces of
test/utilhave changedScripts in
scripts/that were copied over to the Contrib repo have changedConfiguration files that were copied over to the Contrib repo have changed (when consistency between repositories is applicable) such as in
pyproject.tomlisort.cfg.flake8When a new
.github/CODEOWNERis addedMajor changes to project information, such as in:
README.mdCONTRIBUTING.mdYes. - Link to PR:
No.
Checklist: