Some are intentionally or accidentally splitting RPCs across different span IDs. For example, they might intentionally fork a span ID when receiving B3 headers. This could also happen when an intermediary forks a new span, but fails to report it to Zipkin. In either case, the client ends up as a parent span as opposed to the same span as the server.
The goal of this issue is to support the case where a client span is a parent of the server span in the existing model. This is a precondition of any work that assumes single-host (like #939), or at least a warning of what glitches will occur until single-host RPC spans are supported.
Here are the main feature areas to explore:
transparent proxies should be unimpacted as they just sent headers across without changing them or reporting anything to zipkin anyway.
cc @openzipkin/instrumentation-owners @fedj @openzipkin/core @cburroughs @rogeralsing