SOFA RPC client span remains open when a custom async transport bypasses FilterChain.onAsyncResponse

Describe the bug

The SOFA RPC instrumentation starts a client span for an asynchronous consumer invocation and stores its tracing state on the original SofaRequest. The span is completed later from Filter.onAsyncResponse(...).

A custom asynchronous transport callback can receive the response or exception and invoke the application callback directly without notifying the consumer FilterChain. In that case, the client span remains open and is not exported.

The application-facing API may still behave synchronously; “asynchronous” here only refers to the transport response lifecycle.

Steps to reproduce

1. Run a SOFA RPC consumer with OpenTelemetry Java Agent 2.29.0 and the SOFA RPC instrumentation enabled.
2. Use a custom asynchronous transport callback that retains the original ConsumerConfig and SofaRequest.
3. In onResponse or onException, invoke the application callback directly without calling FilterChain.onAsyncResponse(...).
4. Send one successful request and one failing request.
5. Inspect exported spans.

A minimal callback shape is:

final class CustomInvokeCallback {
  private final ConsumerConfig<?> consumerConfig;
  private final SofaRequest request;
  private final SofaResponseCallback callback;

  void onResponse(Object rawResponse) {
    SofaResponse response = convert(rawResponse);
    callback.onAppResponse(response.getAppResponse(), request.getMethodName(), request);
  }

  void onException(Throwable error) {
    callback.onAppException(error, request.getMethodName(), request);
  }
}

Expected behavior

Successful and failed requests each produce exactly one completed SOFA RPC client span. The span retains the original parent, records the correct outcome, and covers the transport duration.

Actual behavior

The request-side tracing filter starts the span, but no asynchronous filter completion occurs. The client span therefore remains unfinished and is not exported.

Javaagent or library instrumentation version

OpenTelemetry Java Agent 2.29.0

Environment

• JDK: Java 8 application runtime
• OS: Linux
• SOFA RPC: 5.12.x-compatible runtime

Additional context

Would the maintainers accept a generic, strongly typed, idempotent completion entry point for custom asynchronous transports/extensions in the existing sofa-rpc-5.4 instrumentation?

The proposed behavior would:

• reuse the current SOFA RPC client instrumenter;
• complete only tracing state already created for the original request;
• be safe when state is absent or already completed;
• avoid running the full filter chain or any application filters;
• add no new span, propagator, exporter, or user configuration.

If this lifecycle must instead be fixed exclusively by the transport implementation, guidance on the preferred ownership boundary would be helpful.

Start in the existing sofa-rpc-5.4 instrumentation, following the request-side tracing filter and Filter.onAsyncResponse(...) completion path. Inspect how tracing state is stored on SofaRequest and how ConsumerConfig and SofaResponseCallback are used by custom transports. Done means successful and failed direct callbacks each complete exactly one existing client span, preserving its parent and transport duration without running the filter chain.