Found two blocking telemetry gaps:

1. gRPC client streams never produce the terminal span or duration metric. The new wrapper relies on its errorConsumer being called with null on successful completion, but gRPC EventStreamObserver.onCompleted() is a no-op. Successful gRPC streams therefore omit <method>-end and gen_ai.client.operation.duration. Please signal completion through the callback (or add a completion callback to the client transport contract) and cover it with a gRPC integration test.

2. gRPC server streams commonly bypass the new terminal instrumentation. The decorator forwards the underlying subscription directly. The gRPC handler cancels that subscription when it sends a final task-status event, then closes the wire stream without invoking the decorator subscriber’s onComplete(). This skips the server <method>-end span and streaming-duration histogram for the normal final-status path, as well as client cancellation. Please intercept Subscription.cancel() or ensure the handler signals completion through the decorated subscriber.

• P1 — REST streams never finish the new client telemetry. OpenTelemetryClientTransport.java:173 relies on errorConsumer.accept(null) to create the closing span and record the duration. RestTransport currently discards its SSE completion callback for both streaming methods, so a normally completed REST stream produces neither the -end span nor gen_ai.client.operation.duration. Update REST completion handlers to signal the listener/consumer with null (as JSON-RPC now does), and add a REST completion test.