Yeah, that’s correct - and that’s why since I wrote that other comment I made up my mind to switch to fly-traceparent / fly-tracestate headers, so that you can use those if you really want to, but it won’t overwrite anything.
I’ll post in this thread when that’s done 
That change has been deployed everywhere.
@jpandersondev and anyone following along: the default sampler configuration should work for you again now
Yes, it is actually the Otel Spec that defines this, so all implementations will be defaulting to this.
You probably are already thinking about this but it would be great if you in the future made traceparent a child of the incoming request’s traceparent, if there is one, and gave the user a way to export your spans as well :). At least for the proxy that is.
It made me think of the router stats we provided users for their requests in the Heroku router, but way better
BAHH, I was trying to make a joke and it didn’t thread correctly. Thanks for looking at this and explaining it.
Ok, I said I was going to write this up, but the end result is a noop because of the change @amos made. The original article I was working from is 100% correct and works for me now. Thanks everyone!
Best community collab ever. Thank you for being patient with us.
Original author of referenced blog post here. What a journey! This was super interesting to follow and I’m glad it was resolved. Thank you everyone!
So, that used to be the case but we lost that when I switched it to fly-traceparent headers - however as you point out, until we provide a way to export spans to somewhere user-visible, it doesn’t really make a difference to you
I’m excited to ship that feature but it requires making design decisions + setting up a multitenant exporter - there’s a bit of work left for me!
@amos did you get around to exposing fly-traceparent headers? I’d love to get that data into lightstep