Activating ClientServerSameSpan resulted in duplicated binnary annotations

[embs]

Setting

zipkin.ClientServerSameSpan(true)

in microservices-demo/user#53 caused the shared span to come up with duplicated http.method and http.url binnary annotations (fames marked with 3 in figure below):

Is there a way to make the tracer not to add annotations if their keys are already present in the span?

Thanks!

[codefromthecrypt]

It can't know if there's something already in the span (from another node). This is basically a UI concern. this one.. right? openzipkin/zipkin#989

[embs]

Thanks, @adriancole.

I wonder why there are no duplicated binary annotations for traces between Java <-> Java (instrumented with sleuth) services interactions which are also sharing span (at least as I can tell):

This span (managed by sleuth) doesn't seem to be in accordance with this assertion:

At least htrace, opentracing, google cloud trace and sleuth use single-host spans.

As it looks like that both nodes are writing to the same span.

Do you know how sleuth manages not to adding dupes into the bin annotations?

[codefromthecrypt]

Some avoid dupes by only writing certain tags on client and others on server. The key here is that if there are dupes with same value we can dedupe them in javascript. About single host span, it is still common in zipkin to have client and server write the same ID. This makes the span detail easy as you see complete rpc in one pane. Duplication is a known issue and can be killed in probably less time than discussing it :) The different values here are largely due to a bug where one tracer is only writing the path for the http.url tag (we have http.path tag)

[embs]

Thank you again for the clarifications, @adriancole.

Then I'm closing this issue as

1. Duplicated annotations keys is not a real problem
2. Improve UX when multiple binary annoations exist in the same span, with the same key openzipkin/zipkin#989 exists for handling duplication within UI

As per

The different values here are largely due to a bug where one tracer is only writing the path for the http.url tag (we have http.path tag)

I'm aware that the wrong value is being written by the go instrumentation code but I'm not sure in which part of it the bug lives. I'll try and file an issue as soon as I discover it out.