Tracking issue for StreamTracer APIs being experimental

[zhangkun83]

[zhangkun83]

We may consider introducing a ClientCallTracer interface:

abstract class ClientCallTracer extends ClientStreamTracer.Factory {
  void onClose(Status status) {}
  abstract class Factory {
    abstract ClientCallTracer newClientCallTracer(...);
  }
}

Then remove CallOptions.withStreamTracerFactory(), instead set the ClientCallTracer.Factory in the channel builder.

Using ClientCallTracer means:

1. No need to copy the CallOptions in interceptor, which generally means less allocation
2. Tracers can only be set up on channel builder, not per-call basis
3. With dedicated interface it may be easier to support recording of more events that are not exposed to client interceptor

[dapengzhang0]

Why doesn't ClientStreamTracer.inboundTrailers(Metadata trailers) include Status, or at least Status.Code in the argument?

[zhangkun83]

It was not needed, and streamClosed() already takes the status. Do you need it now?

[dapengzhang0]

I didn't know there is streamClosed(), then that would be sufficient, no need to add anything.

[anuraaga]

Hey - it's been a few years, any plans for marking this API stable? I was thinking of using this in OpenTelemetry instrumentation but want to avoid compatibility issues there.

/cc @bogdandrutu

[larry-safran]

OpenTelemetry will need some methods, but that is an implementation detail so these will not need to be stabilized to support OT.

[thejas-stripe]

We have a way to inspect inbound trailers

public void inboundTrailers(Metadata trailers) { }

the inboundHeaders does not have the headers available as argument

public void inboundHeaders() { }

Any reason for this ? can we support public void inboundHeaders(Metadata headers) { }