-
Notifications
You must be signed in to change notification settings - Fork 652
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
Propagators must not return an invalid span if nothing could be extracted from the carrier #1765
Propagators must not return an invalid span if nothing could be extracted from the carrier #1765
Comments
These issues/PR might be of your interest:
The discussion was already started, however I also believe problem is not fully solved yet. |
Looks like the outcome of the discussion in #1732 was to return a context with an |
It could come as very surprising for me if current context is used as parent span context when there is some deserialization error extracting remote span context.
Spec doesn't say that unsuccessful extract the propagator has to return the unmodified current context. It only says if there is a passed in context and If a value can not be parsed from the carrier, in order to preserve any previously existing valid value we shouldn't modify it (which we are doing now for b3 and should be updated for others). I would be fine with seeing two or more traces which ideally should be under one trace because I messed up serialization but if I find spans under some different trace it is incorrect and strange. From what I can see in linked the other languages they make it mandatory to pass context unlike python. If there is issue with doc string or it conveys wrong message then we should update it or reword it but I don't think we shouldn't return unmodified current context. |
I can see the problem of the propagator continuing the current active trace if there is a deserialization problem and returning the current context will exactly lead to this behavior. Looking at the b3 propagator it returns a mix of current and "root" context by appling the INVALID_SPAN to the current context. This looks somewhat strange to me. Wouldn't it make more sense to just use the root context as default if no context argument was provided (i.e. define root context for extract if none was provided)?
A call like |
@mariojonke |
Currently most propagators set an
INVALID_SPAN
into the context onextract
in case a value cannot be parsed from the carrier (see tracecontext, b3, jaeger).Spec however states that a new value must not be set in such a case:
Propagators should return the passed in context (or the current one if none was given) if nothing could be extracted. Also in other language SIGs (go, java, dotnet, ...) just the unmodified context is returned.
The text was updated successfully, but these errors were encountered: