@Test void redundantServiceNameOnAddressAnnotations_serverRetainsClientSocket() {
    Span v2 =
      Span.newBuilder()
        .traceId("1")
        .parentId("2")
        .id("3")
        .kind(Kind.SERVER)
        .name("get")
        .localEndpoint(BACKEND)
        .remoteEndpoint(FRONTEND.toBuilder().serviceName(null).build())
        .timestamp(1472470996199000L)
        .duration(207000L)
        .build();

    V1Span v1 =
      V1Span.newBuilder()
        .traceId(1L)
        .parentId(2L)
        .id(3L)
        .name("get")
        .timestamp(1472470996199000L)
        .duration(207000L)
        .addAnnotation(1472470996199000L, "sr", BACKEND)
        .addAnnotation(1472470996406000L, "ss", BACKEND)
        .addBinaryAnnotation("ca", FRONTEND.toBuilder().serviceName("backend").build())
        .addBinaryAnnotation("sa", BACKEND)
        .build();

    assertThat(v1SpanConverter.convert(v1)).containsExactly(v2);
  }
On server spans, ignore service name on remote address binary annotation that appear loopback
based on the service name. This could happen when finagle service labels are used incorrectly,
which as common in early instrumentation.

<p>This prevents an uncorrectable scenario which results in extra (loopback) links on server
spans.
zipkin/src/test/java/zipkin2/v1/SpanConverterTest.java