additional annotations are shown twice in Zipkin GUI

[janolaveide]

Following the advice in the 3.4 release notes, I subclass the span collector in order to decorate the collect method. The annotation added picks a value from MDC, but I guess that is irrelevant.

@Override
public void collect(Span span) {
   span.addToBinary_annotations(new BinaryAnnotation("correlationId", MDC.get("MDC-correlationId")));
   super.collect(span);
}

However, the annotation is listed twice in the GUI.

[codefromthecrypt]

the weird part is that the existing scribe code did this inside collect (basically the same code as you have)! You aren't adding to defaultAnnotations anymore, right?

        if (!defaultAnnotations.isEmpty()) {
            for (final BinaryAnnotation ba : defaultAnnotations) {
                span.addToBinary_annotations(ba);
            }
        }

[janolaveide]

No, I don't. A breakpoint in that section never triggers, so defaultAnnotation is indeed empty

[codefromthecrypt]

cool thx for verifying

[eirslett]

What does the JSON API response look like? Is the problem at zipkin-query or in the frontend UI?

[codefromthecrypt]

root issue was that the client and server were both logging the same binary annotation. Binary annotations look like a dict String->String, but there's actually no unique constraint. I recommended adding the correlationId only on the server span (ie. looking for "sr" annotation and doing it then).

[eirslett]

I recommended adding the correlationId only on the server span (ie. looking for "sr" annotation and doing it then).

+1. Alternatively, live with the fact/problem that it's duplicated in the UI 😉
@yurishkuro had a patch that adds the service name to every annotation in the UI, to disambiguate - at least, that's what I think you meant? Though that work was stalled by all my refactoring that probably ruined the patch...

[codefromthecrypt]

well, in this case neither binary annotation had a host/endpoint attached :P but yeah get what you mean.