Propagate Azure Functions invocation IDs in Durable client gRPC metadata #309

Summary

The Java Azure Functions Durable client binding does not propagate the originating function invocation ID in gRPC metadata. The host therefore cannot correlate supported client-operation logs with the calling function invocation, leaving the Java portion of Azure/azure-functions-durable-extension#3327 blocked.

This is a source-inspection report. It concerns the Azure Functions integration, not standalone Java applications or new orchestration features.

Current behavior and source evidence

Verified on main at dcd243b2822f5b35e0a28d23193fdf259431871d:

• DurableClientContext has no invocation-ID field or invocation-context parameter in getClient() and obtains its client through DurableTaskGrpcClientFactory.getClient(rpcURL.getPort(), null).
• The gRPC client factory caches clients by port, so any solution must not retain one invocation's ID on a shared client for later invocations.
• The host gRPC contract expects the metadata key x-azure-functions-invocationid.

Reproduction and expected behavior

Use the Azure Functions Durable client binding from a function with a known invocation ID and capture the outgoing gRPC metadata for a supported client operation. Provide a backward-compatible path from the originating Functions execution context to each call so that the metadata value equals the function invocation ID. A trace ID, span ID, or orchestration instance ID is not a substitute.

Acceptance Criteria

• Azure Functions callers have a backward-compatible way to associate their current invocation ID with supported Durable client calls.
• The invocation ID is included as x-azure-functions-invocationid on supported host-logged client operations.
• Regression tests verify outgoing gRPC metadata for distinct invocations, including concurrent calls and clients obtained through the port-cached factory, without stale or cross-invocation ID leakage.
• Missing invocation context preserves existing behavior; standalone Java clients do not fabricate Functions invocation IDs.
• Existing gRPC metadata, tracing behavior, and client APIs remain compatible. This work does not require adding rewind or other currently unsupported Java features.
• Record the published Azure Functions Java integration artifact/version containing the fix so the extension E2E dependency and Java assertions can be updated.

Related

• Parent tracking: Azure/azure-functions-durable-extension#3327.
• Current extension E2E language gate.

This is distinct from entity OpenTelemetry trace-context propagation: it supplies the Functions invocation GUID needed by the host's ClientOperationReceived logs. Mandatory extension E2E assertions follow after release.