[Azure Functions v2] Propagate function invocation IDs in client gRPC metadata #314

Summary

The azure-functions-durable v2 Azure Functions integration in this repository does not forward the originating function invocation ID in client gRPC metadata. This prevents the host's ClientOperationReceived logs from being correlated with the calling function invocation.

This tracks the next-generation Python SDK dependency for Azure/azure-functions-durable-extension#3327. It is distinct from the stable v1 HTTP purge omission tracked in Azure/azure-functions-durable-python#630.

Package and release scope

• Package: azure-functions-durable, in this repository's azure-functions-durable directory, not the standalone core durabletask package.
• Published preview verified on PyPI: 2.0.0rc3, requiring Python >=3.13.
• The missing metadata is present in both the published rc3 source tag and the current source revision below.

This report is based on source and package-metadata inspection, not a deployed-application incident.

Current behavior and source evidence

Verified on main at d2a3e7fc096b36a9bb6927f66adb4caa40bb9425:

• _build_metadata and the sync/async Functions interceptors only add taskhub and x-user-agent.
• The async client constructor uses the Functions interceptor and supplies metadata=None to the base client. The sync constructor follows the same pattern.
• internal/invocation.py preserves Functions invocation context for synchronous code, but this context is not connected to the gRPC metadata builder.
• The host contract expects x-azure-functions-invocationid containing the originating Functions invocation GUID.

Reproduction and expected behavior

Create a Functions-bound client under a known invocation context and capture outgoing gRPC metadata for a supported host-logged client operation. Repeat for async and sync client paths. The current Functions interceptors add routing/user-agent metadata but omit the invocation ID. The expected metadata value is the originating func.Context.invocation_id, not a trace ID, span ID, or orchestration instance ID.

Acceptance Criteria

• Functions-created async and sync clients propagate the current invocation GUID as x-azure-functions-invocationid on supported host-logged client operations.
• Transport-level regression tests verify the metadata for both client paths, including compatibility shims where applicable, rather than only testing a metadata-builder return value.
• Tests cover distinct and concurrent invocations, thread-offloaded sync execution, and reused/cached clients without stale IDs or cross-invocation leakage.
• Missing Functions invocation context preserves existing behavior; no ID is fabricated for standalone Durable Task/DTS clients.
• Existing routing, user-agent metadata, tracing behavior, and client/channel lifecycle remain compatible.
• Record the fixed published Functions SDK version and add/coordinate host-backed correlation coverage so the dependent extension E2E assertions can become mandatory for this SDK line.

Related

• Parent tracking: Azure/azure-functions-durable-extension#3327.
• Stable Python v1 HTTP purge tracker: Azure/azure-functions-durable-python#630.

The scope is the Functions v2 adapter's invocation-correlation metadata, not adding Azure Functions assumptions to the generic SDK or redesigning distributed tracing.