Orchestration response started containing entirely different/incorrect URLs

[jaliyaudagedara]

Description

We have a .NET 10 isolated Durable Function App that has a Netherite backend deployed to Azure Container Apps with --kind = functionapp.

After deploying a new version that includes functionality to purge instance histories, and when purge instance histories is invoked, noticed that new the orchestration responses contains entirely new set of URLs.

Note the https://apimwebappkdmkqledodgytbcpbgosiuujidjzdhf9mpxzyob6.azurewebsites.net which we have no idea about . Correct one should be something like https://<container_app>.azurecontainerapps.io

Expected behavior

Orchestration Response should contain correct URLs

Actual behavior

Orchestration Response contains incorrect URLs

Relevant source code snippets

N/A

Known workarounds

N/A

App Details

• Microsoft.Azure.Functions.Worker.Extensions.DurableTask: 1.12.1
• Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite: 3.1.0
• Microsoft.Azure.Functions.Worker: 2.51.0
• Microsoft.Azure.Functions.Worker.Sdk: 2.0.7

If deployed to Azure

Orchestration instance ID(s):

Incorrect:

e082c44d7c264f9b8261b0bb5b92eaa7
8c686af023774313a52226bb0e8d4f33
04aa079e945249c990d179b47d45ce51
38d9027b1c2449ba934ad20bac9d7f14
e0d274520b8745539b7339584c0b427f

Correct:

a78950aa204c4d24ac66ee00ddc453c7
ae069159f25547fda2d9b4ac32306acf
9f47e197921843ecafa44b1ca0c44f3c
1495f26c87cf45969c9d52a6151244b9
cb5379e84bdb4b8892535e78503fbfe9

NOTE: We had to revert the change as we are depending on Orchestration Response URLs and the incorrect URLs were getting 504 Gateway Timeout.

[NoleNerd]

Upon further review, we have found several instances where this issue was present before the release of new code that included the Purge Instance History functionality. Also, we're currently seeing these azurewebsites.net URLs in responses after we switched back to the prior release.

The earliest instance that we've been able to find occurred at 2026-01-07 17:42:46.0061221 +00:00 UTC which is well before when we started any deployment (deployment of code started around 2026-01-08 02:00:00 +00:00 UTC). Notice in the screenshot below that there was an 11 minute difference between the expected responses and the unexpected responses. We've only seen the azurewebsites.net URLs in the responses since this time.

Azurewebsites.net response instance ids

4ad96805ad144a4a807098cc68444b5c
61baa3d1330944798839c541c649a54f
d9f1745be93142ba9b9e06304785ed22
a331af35215348259d0f541a7fa54ba1
1beff5e270b04eb993254555737ace60

The last azurecontainerapps.io response instance ids

a9bfd30a877f4295a00b43ae515177e4
4f6d8e3ea33f4b8ba00a0254c9335529
0e6734d061a64ab689fc91c2963f6688
faea6fc69939479e896d632758a8dc87
09d9d747bd83406daeb5645554bed6fb

Here are some additional occurrences:

[torosent]

@jaliyaudagedara we will take a look but also note that Netherite is on a retirement path so please consider migrating to another backend such as Durable Task Scheduler.
https://azure.microsoft.com/en-us/updates/?id=489009

[jaliyaudagedara]

Thanks @torosent, appreciate.

I can definitely understand if it's related to Netherite. But I am more inclined to think it's something to do with ACA Ingress forwarding headers.

And also we experimented DTS while ago (3, 4 months), but it's performance wasn't close to Netherite. So we backed out. Believe there are improvements since then, we will give it another try.

[torosent]

@jaliyaudagedara, can you add the environment variable ASPNETCORE_FORWARDEDHEADERS_ENABLED=true?
Also, can you the WEBSITE_HOSTNAME environment variable and what is the version you reverted to?

[jaliyaudagedara]

We have added AzureFunctionsJobHost__extensions__durableTask__httpSettings__useForwardedHost=true and that seems to have fixed the issue.

The first occurrence was at 2026-01-07 17:42:46.0061221 +00:00, and that was well before our deployment. And today even after reverting, noticed the same issue. So it's not related to our code changes.

[jaliyaudagedara]

Well, it's still happening intermittently. Checked all the replicas, it has the environment variable AzureFunctionsJobHost__extensions__durableTask__httpSettings__useForwardedHost=true.