Open codefromthecrypt opened 6 years ago
@adriancole How would you handle the transition phase when not all services have been updated to accept the new header?
The client cannot know if the server supports it or not since we don't do any protocol negotiation. Would people need to wait until all their servers have been upgraded before changing the client code?
yes.. server first, just like when we did 128bit trace ID. that is why it is a bit more urgent to update middleware.. in order to start that transition.
dual propagation downstream is possible but yeah simpler to start with making everything understand parsing both.
On Tue, 9 Oct 2018, 23:49 Daniele, notifications@github.com wrote:
@adriancole https://github.com/adriancole How would you handle the transition phase when not all services have been updated to accept the new header?
The client cannot know if the server supports it or not since we don't do any protocol negotiation. Would people need to wait until all their servers have been upgraded before changing the client code?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Yelp/py_zipkin/issues/98#issuecomment-428246158, or mute the thread https://github.com/notifications/unsubscribe-auth/AAD61zqPnDmAXFF2labM3x1yLzoRNyb9ks5ujMWggaJpZM4WQ_VH .
As discussed on https://github.com/openzipkin/b3-propagation/issues/21 and first implemented here: https://github.com/openzipkin/brave/blob/master/brave/src/main/java/brave/propagation/B3SingleFormat.java https://github.com/openzipkin/brave/blob/master/brave/src/test/java/brave/propagation/B3SingleFormatTest.java
Let's support at least reading "b3" header from a single string, most commonly traceid-spanid-1 It would also be nice to support optionally writing this, especially in message providers or others with constrained environments.
Brave currently has a property like this, but its name could change with feedback: