-
Notifications
You must be signed in to change notification settings - Fork 35
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
Make SpanContext
sealed
#359
Make SpanContext
sealed
#359
Conversation
9c58514
to
762a460
Compare
sealing it is the first breaking API change since 0.3.0 was released (🎉) so we need to bump the base version. Line 3 in 762a460
|
TraceFlags.fromByte(jSpanContext.getTraceFlags.asByte) | ||
|
||
lazy val traceState: TraceState = { | ||
def wrap(context: JSpanContext): SpanContext = { |
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.
Nit: is wrap
the correct terminology anymore?
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.
We can rename WrappedSpanContext
to SpanContextConversion
?
object SpanContextConversion {
def toJSpanContext(ctx: SpanContext): JSpanContext
def toSpanContext(ctx: JSpanContext): SpanContext // or fromJSpanContext
}
context.getTraceState.forEach((k, v) => entries.addOne(k -> v)) | ||
val traceState = TraceState.fromVectorUnsafe(entries.result()) | ||
|
||
SpanContext( |
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.
This is re-validating it right? Probably not a big deal but I suppose we could use some sort of unsafe constructor to skip validation in this specific case.
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.
Yes, it will re-validate inputs. We can use SpanContext.createInternal
instead.
I forgot. It's a breaking API change, indeed. My disappointment is immeasurable and my day is ruined. It means once we merge the PR, we cannot release patches (e.g. bugfix) for 0.3 anymore. Should we make two |
If the need to publish bug fixes arises, we can cut a Edit: another option if there are bug fixes to release is to just declare |
770d804
to
dc2f0ed
Compare
dc2f0ed
to
10f003f
Compare
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.
LGTM but I look forward to finding out what I missed when April takes a look 😅
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.
no significant concerns—just a few nitpicks and some bikeshedding
import org.typelevel.otel4s.trace.TraceState | ||
import scodec.bits.ByteVector | ||
|
||
private[otel4s] object SpanContextConversion { |
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.
should probably be called SpanContextConversions
(plural)
|
||
private[otel4s] object SpanContextConversion { | ||
|
||
def fromJSpanContext(context: JSpanContext): SpanContext = { |
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.
thoughts on toScala
for this one and toJava
for the other? a bit shorter name-wise and consistent with what the stdlib does for its conversions.
how often will end users need to use these conversions? if it's not super rare, extension methods would probably be a nice touch, though I'm happy to handle that if it ends up being needed
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.
Much better than fromJSpanContext
and toJSpanContext
, thanks!
ctx.traceIdHex, | ||
ctx.spanIdHex, |
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.
any particular reason to use the hex String
s for the Hash
rather than the ByteVector
s?
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.
There is no Hash[ByteVector]
instance, unfortunately.
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.
Oh, we can inline a quickie one with Hash.fromUniversalHashCode()
. I think instances might live in scodec-cats
but not worth dragging that in ...
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.
Is there any benefit of using traceIdHex
vs traceId
? Since we treat traceId
as a 'primary' property, we should use it in hashing too, right?
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.
Since we treat
traceId
as a 'primary' property, we should use it in hashing too, right?
That's my thinking as well.
isValid = isValid | ||
) | ||
|
||
private final case class SpanContextImpl( |
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.
extreme nitpick: should this just be called Impl
, as it's already inside the SpanContext
companion?
if it doesn't have to do with the collections or at least the stdlib, usually nothing (as demonstrated) |
# Conflicts: # java/trace/src/main/scala/org/typelevel/otel4s/java/trace/WrappedSpanContext.scala
a2c1349
to
2a1f332
Compare
Motivation
Once the trait is sealed, we are in control of the implementations. And we can define a safe
Hash
instance.otel4s-java-trace
uses OpenTelemetry Java SDK under the hood.Currently, we need to convert
SpanContext
toJSpanContext
in 3 cases:SpanBuilder
has links: e.g.Tracer[F].spanBuilder("child").addLink(otherSpan.context)
Tracer[F].spanBuilder("child").withParent(otherSpan.context)
Tracer[F].childScope(otherSpan.context)
I've experimented with
delegated
instance too, see SpanContext and WrappedSpanContext.However, Arman raised a valid concern that this approach violates the specification:
Warning
The API MUST implement methods to create a SpanContext. These methods SHOULD be the only way to create a SpanContext. This functionality MUST be fully implemented in the API, and SHOULD NOT be overridable
Considering that we need to convert
SpanContext
toJSpanContext
rarely, in my opinion, we don't need a delegate instance.WDYT?