but the actual tasks invoked are async
usually you, if have the choice anyway, wouldn't put a span around polling
underneath it is polling
would be surprised for a blocking task to actually go that long
but I'm often surprised :D
but normal requests, like app requests.. mostly should just wait for completion
np
I wish there was a way to have spans for loop iterations
or did I not get the question?
Not with the help of span context
I see. If you are not in control of the spans that are generated then probably the only way to do it is to modify them on reporting. Like before sending it to the tracing server, you modify the spans that are part of a loop to become a single span and every span marked as an annotation.
About "Google's golang client" is that published somewhere?
@Pradnyilkumar_twitter it is described here: https://github.com/openzipkin/brave/tree/master/brave#propagation
most instrumentation that need to parse headers already do that, so might be better to ask why you need to change the parent id/parse your own request https://github.com/openzipkin/brave/tree/master/instrumentation
It's 100% reproducible - I can download the spans from
/api/v2/trace/{traceId}, remove any spans with "finagle.flush"+"ws" and upload the result directly in the UI and it displays correctly
that you have flush and no "wr" means the client didn't finish before the timeout https://github.com/openzipkin/zipkin-finagle/blob/66681378c5e78341c13a10bd70e4232744f17187/core/src/main/java/zipkin2/finagle/SpanRecorder.java#L161
so 2 minutes
you could verify by looking at the difference between timestamp and "ws"
it could be that the request was long, or somehow the client finish hook got lost somehow
what client was it?
if it is consistent, possible to debug using zipkin-junit in a unit test
or look at the tracer logs and not use a real tracer
but yeah sounds then like a missing finish..
was it one-way RPC?