[Azure Functions] Simplify large-payload configuration by reusing an existing storage connection

[andystaples]

Community feedback wanted

Would you use a simpler way to configure large-payload storage in the azure-functions-durable v2 SDK using a storage connection your Function App already has?

Please add a thumbs-up reaction to this issue if this would help, and comment with your use case. In particular:

• Would you use the Function App's host storage (AzureWebJobsStorage), a separate Azure Storage backend account, or another named connection?
• Do you use a connection string, system-assigned managed identity, or user-assigned managed identity? Is local development with Azurite important?
• Would explicitly choosing a connection name be sufficient, or is automatic discovery of the Durable backend's account important?
• Is constructing a BlobPayloadStore explicitly a meaningful obstacle today?

This issue is gathering demand and requirements, not committing to an API or delivery timeline.

Context

PR #270 adds explicit configuration through DFApp.configure_large_payloads(payload_store=...). We are keeping that implementation simple: applications supply their own payload store.

A potential follow-up would reuse existing Functions storage configuration so users do not need to construct a blob store or repeat connection-resolution code. Host storage and the Azure Storage Durable backend often use the same account, but can be configured separately.

Possible direction

Illustrative API only; these convenience forms are not implemented:

app.configure_large_payloads()  # Opt in, using AzureWebJobsStorage

app.configure_large_payloads(connection_name="DurableStorage")

Calling the API would remain an explicit opt-in to SDK payload externalization. The existing payload_store=... form would remain available for full control, mutually exclusive with connection-based configuration.

Automatic discovery of the Azure Storage backend's account is a separate option to evaluate based on feedback, rather than a prerequisite for a named-connection helper.

Design considerations

• Resolve both connection strings and identity-based connection settings, including identity selection and local development behavior.
• Backend discovery would need to honor effective host configuration, environment overrides, and supported aliases. The Python SDK does not currently receive a resolved backend storage configuration.
• Account selection must be stable across workers and deployments so existing payload references remain readable. Client bindings targeting other connections also need consideration because payload configuration is currently process-wide.
• Use a dedicated SDK payload container, not the backend's large-message container. Sharing an account does not make backend purge clean up SDK payload blobs; permissions and retention remain important.
• Azure Storage backend large-message handling and SDK payload externalization are separate mechanisms. This proposal only simplifies configuration of the latter.

References: Functions host storage settings and Durable Azure Storage connection configuration.