[andystaples]

Summary

Functions-bound async and synchronous clients now send the originating func.Context.invocation_id as x-azure-functions-invocationid, allowing the host's ClientOperationReceived logs to correlate client operations with the calling function invocation.

The binding wrapper captures and resets invocation-local context while preserving synchronous/asynchronous dispatch and existing function annotations. Both Functions interceptors resolve the ID on each RPC rather than retaining it on a client or channel, matching the .NET Functions SDK's call-time correlation model. Cached synchronous clients, concurrent invocations, and thread-offloaded synchronous calls therefore use the current invocation's ID. Existing routing, user-agent, and caller metadata are preserved; calls without Functions invocation context do not gain a fabricated ID. Generic Durable Task and DTS clients are unchanged.

Regression coverage

• Real gRPC transport coverage for both client paths, including async compatibility aliases, concurrent invocations, cached/reused clients, thread offloading, existing metadata, and missing invocation context.
• Invocation context cleanup after function failures.
• Mandatory host-backed correlation assertions for concurrent async and sync starters: the host log must contain the exact originating invocation GUID for each started instance. Missing correlation logs fail the tests.

Release coordination

This change applies only to azure-functions-durable and is recorded under its unreleased changelog. 2.0.0rc3 remains unfixed; a fixed published version is not yet available and should be recorded when the next Functions SDK release is published. No package versions or dependency minimums are changed here.

The extension E2E matrix must explicitly select that fixed Python v2 release with Python 3.13+ before making its corresponding SDK-line assertions mandatory. That dependency/version handoff remains tracked in Azure/azure-functions-durable-extension#3327; this does not change the separate stable Python v1 purge tracker.

Fixes #314.

[Copilot]

🟡 Changes recommended

The wrapper mistakes binding data named context for runtime context, causing client RPCs to fail with AttributeError; it must preserve the binding, omit unavailable correlation, and add regression coverage.

1 open issue

• Binding named context breaks client RPC invocation correlation · New

What changed in this PR

This PR adds invocation-ID correlation to Azure Functions v2 client RPCs, allowing host logs to identify the calling function invocation without changing generic Durable Task or DTS clients.

Changes:

• Capture invocation-local context while preserving synchronous and asynchronous dispatch.
• Resolve invocation IDs per RPC so cached clients use the current invocation’s ID.
• Add transport and host-backed regression coverage and document the Functions-specific fix.

File	Description
tests/​azure-functions-durable/​test_invocation_metadata.py	Tests transport metadata, concurrency, client reuse, and context cleanup.
tests/​azure-functions-durable/​e2e/​test_dtask_client_e2e.py	Adds host-log correlation assertions for concurrent starters.
tests/​azure-functions-durable/​e2e/​apps/​dtask_style/​client_routes.py	Adds async and sync correlation endpoints.
azure-functions-durable/​CHANGELOG.md	Documents the invocation-correlation fix.
azure-functions-durable/​azure/​durable_functions/​internal/​invocation.py	Adds invocation-ID lookup and sync-compatible context wrapping.
azure-functions-durable/​azure/​durable_functions/​internal/​azurefunctions_grpc_interceptor.py	Adds invocation metadata at RPC call time.
azure-functions-durable/​azure/​durable_functions/​decorators/​durable_app.py	Wraps client-bound functions with invocation-context capture.

_{Review effort: Balanced}

[Bernd Verst (berndverst)]

The call-time invocation-local metadata approach addresses the correlation gap without changing generic Durable Task/DTS clients or sacrificing synchronous client reuse. I confirmed one runtime compatibility regression: a valid binding named context is captured as if it were func.Context, so both sync and async client RPCs fail before reaching the host. This reproduces for durable_client_input(client_name="context") and activities with activity_trigger(input_name="context") plus a client, in either decorator order; the base succeeds for all cases. Please address the existing context-binding thread by preserving bound data and omitting correlation when no real runtime context exists, with regression coverage. I found no other actionable defects or material performance/replay issues.

[Bernd Verst (berndverst)]

Re-reviewed 5a0ed30. The context-named binding regression is fixed: both sync and async clients now preserve binding data and omit unavailable correlation, including activity/client bindings in either decorator order. All six previously failing real-gRPC reproductions now pass, the 91 related tests pass, and normal invocation-local correlation remains intact. I found no remaining actionable defects, material performance regressions, or compatibility concerns.