-
Notifications
You must be signed in to change notification settings - Fork 845
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
Allow SpanProcessor#onStart to modify received Span #1569
Comments
This is relatively recent spec change, and yes, we need to get the implementation updated! Thanks for pointing it out! |
I think we might want another interface for this which joins the readability of the ReadableSpan and the write-capability of the Span itself. |
(Or pass both) |
I think passing both might be extra confusing for users, especially since we'll be passing the same implementation in for both parameters. :) |
Fair enough. Let's keep the idea of passing both as plan B ;) |
I think it's as easy as this:
Then just have RecordEventsReadableSpan implement that, and change the onStart take the new interface. I'll PR it. :) |
it's that easy except for the Disruptor async exporter which needs a new event type. |
Great, thanks! |
I'm working on it this afternoon. 🤞 that I get the disruptor sorted out by then. |
Is your feature request related to a problem? Please describe.
There's an inconsistency with the spec: it clearly states that
SpanProcessor#OnStart
should receive a read/write instance of Span. Current Java SDK implementation receives only aReadableSpan
which makes implementing anySpan
enrichment/modification inSpanProcessor#onStart()
impossible.Describe the solution you'd like
A proposed solution is to add a second
Span
parameter to theonStart
function - it will provide the "write" capability. I believe that adding a second parameter that represents a write-only span is in accordance with the spec ("...theSpan
could be one of the parameters passed to such a function, or a getter could be provided...").Describe alternatives you've considered
Main motivation for this change is open-telemetry/opentelemetry-java-instrumentation#942 . Instead of adding thread info using a
SpanProcessor
(as was suggested here) I can always just add those attributes directly in the Java agent.Additional context
Related issues/PRs/comments:
The text was updated successfully, but these errors were encountered: