Any breaking changes between DurableFunction v2.5.1 to v2.7.1?

[siemenstan]

I try to upgrade Durable Function library from v2.5.1 to v2.7.1 but my app doesn't work the same like before after the library upgrade. May I know if there any behavior change or do I need to update my configuration?

Below is a simple diagram that illustrate my app running in AKS, there is an API AKS node which handle and delegate the requests to 3 Execution AKS node, through 3 azure storage accounts, each execution node deal with its respective storage account. The storage account will have the same suffix name, eg: AzureWebStorage02b will point to StorageAccountName02b

The API node will call the IDurableClientFactory.CreateClient(...) method to get the durable client, and then call the IDurableClient.StartNewAsync(...) to start the execution orchestration function, below is the code snippet

IDurableClient orchestrationClient = this.durableClientFactory.CreateClient(new DurableClientOptions
{
	ConnectionName = connectionName,
	TaskHub = this.configurationProvider.TaskHubName,
});
orchestrationClient.StartNewAsync(SharedFunctionConstants.ExecuteActionOrchestratorName, instanceId, orchestrationInput);

The durable client options connection name will be one of the 3 values: AzureWebStorage02 / AzureWebStorage02b / AzureWebStorage02c, set in AKS pod environment variable, that contains azure storage account storage connection string.
All this while with Durable Function v2.5.1, this work fine, eg: with ConnectionName of AzureWebStorage02b, the request will go to StorageAccount02b, and Execution-2 node will pick up and execute the job. This also works fine with Durable Function v2.6.1, but not with Durable v2.7.1 or later (didn't test v2.7.0 due to .net6 dependancy issue).
All the requests only write to the StorageAccount02 (which is pointed by variable 'AzureWebStorage02' or 'AzureWebStorage') Is there any behavior changes or configuration changes required which doesn't mention in release note? (Here is the simplified API AKS node environment print: API env.txt)

Below is the instance with Durable Function v2.8.1 on 10-Dec-2022 03:20AM UTC.
The request suppose to write to AzureWebJobStorage02b (StorageAccount02b, and execute by Execution-2 pod) but it actually write to StorageAccount02 (and execute by Execution-1)
Orchestration InstanceId: ce57ffef-6826-498b-8cf1-dca80aab1e28

And, below is the instance with Durable Function v2.5.1 on 12-12-Dec 03:02AM UTC.
The request write to AzureWebJobStorage02b (StorageAccount02b, and execute by Execution-2 pod)
OrchestrationInstanceId d947f0e4-7475-45f2-b8b0-e361823fce0e

Your help is very much appreciated.

[siemenstan]

This is the host.json for the API app (renamed as txt for upload purpose)
host.json.txt

[davidmrdavid]

If there were any breaking changes, they were most likely unintended as we did not make a major version release.
From looking at the release History between 2.6.1 (which I understand works for you) and 2.7.1, it seems likely to me that this difference starting from version 2.7.0 which introduced quite a few changes.

@cgillum: looking at the release notes for Extension v2.7.0, do any of those seem more likely to induce the behavior this user is seeing?

[cgillum]

Ah, that probably explains the regression! As part of the managed identity work, we changed some of the configuration structure around how connection information is managed. One of them was to move connection information into the StorageAccountDetails object. It seems to me that we forgot to update the code that you highlighted. This is a bug that we should absolutely fix. I think if we could generalize your "hack" to consider both StorageAccountDetails and the original StorageConnectionString, comparing any of the different combinations, then it would be robust enough for us to accept and roll out in an update.

[cgillum]

I created a GitHub issue from this discussion here: #2336.

[siemenstan]

Thank you @cgillum . Do you have an estimated time when is the next Durable Function release (assume this issue will be fixed by then)?

[cgillum]

I don't, unfortunately. This issue will need to go through the team triage process.

[cgillum]

That said, we do accept PRs, and if you're willing to contribute one, that's one guaranteed way to get an official release out faster. :)