MergeById should prioritize server spans when merging

[codefromthecrypt]

From @anuraaga on March 25, 2016 15:16

Currently it seems that MergeById will merge spans based on the order provided to it. This will often be the spans in order of timestamp since most stores will index in order. Since client calls happen before a server receives them, this almost always prioritizes client information to server information.

In my experience, servers know themselves better than a client knows the server, and I wonder if server spans should be prioritized during merge. Specifically I'm thinking about span name, which is essentially a service method - it's not unlikely the client will have some generic name for its method like "execute" while the server will know the API called was "spans". There may also be multiple clients, each with slightly different ways of instrumenting, but just one server - prioritizing the server will make sure these are handled consistently (this is literally what I'm seeing in my environment which is causing confusion).

From what I understand, it should be possible to differentiate server and client spans based on annotation - does it make sense to look at these and use server spans as the base wherever possible?

Copied from original issue: openzipkin/zipkin-java#130

[codefromthecrypt]

I know where you are going with this, just that features like this are
pretty expensive without changing schema. For example, to do this in JDBC
(which uses the same schema as openzipkin/zipkin), we'd need to store
something to indicate which side it is on. For example, I pull this
intermediate state here
https://github.com/openzipkin/zipkin-java/blob/master/zipkin/src/main/java/zipkin/internal/DependencyLinkSpan.java

I wouldn't object to best-efforts to do this, as long as it doesn't add
gnarliness. I know there are some approaches folks are using, ex using
empty span names on clients (which makes the server win)

Regardless, this should be a focus area here
#939

[jorgheymans]

It's been a while, closing as no more discussion happened around this. @adriancole if you want to add a conclusion how this is handled currently feel free, if not relevant anymore just ignore :-)