Flex Consumption deployment package repeatedly reverts to old version with no deployment trigger

Question

Flex Consumption deployment package repeatedly reverts to old version with no deployment trigger

Ari Spagat 0

I have a Python Function App on the Flex Consumption plan whose deployed package (released-package.zip) is repeatedly being overwritten with an outdated version approximately every 20-40 minutes, with no corresponding deployment event anywhere I can find.

Environment:

Function App: analytics-ingest (Linux, Python 3.11, Flex Consumption)
Deployment storage: defaultresourcegrou990e / container app-package-analytics-ingest-d0bd37e
Deployed via GitHub Actions using Azure/functions-action@v1

Symptom: A specific file inside my deployed function (function.json, containing a timer trigger schedule) keeps reverting from my intended hourly schedule back to an old daily schedule. I've confirmed this by checking the Last Modified timestamp on released-package.zip directly via az storage blob show, and it changes repeatedly without any new GitHub Actions run in my repo's history.

What I've ruled out:

No new GitHub Actions workflow run occurs when the revert happens (confirmed via Actions history)
Not caused by any local script/cron/LaunchAgent on my own machine (checked directly)
Not related to Azure Cloud Shell (confirmed ephemeral, doesn't retain state between sessions)
Removing remote-build: true from the deployment workflow did not stop it (reverted again 12 minutes after a clean redeploy without that flag)
No Automation Accounts or Logic Apps exist in this subscription

Evidence gathered: I enabled StorageWrite diagnostic logging on the storage account and confirmed writes to this container are made using the Function App's own managed identity (App ID f511c258-d644-492f-9de3-6de829abf656), from internal Azure IP addresses (172.24.x.x range), with kudu as the user agent — but I haven't yet captured the exact write event that causes the revert (only the writes from my own manual redeployments so far).

Question: Is there any known Flex Consumption platform behavior — related to rolling updates, instance specialization, or package caching — that could cause the deployed package to periodically revert to a previous version without an explicit deployment? Or is this indicative of something else I should be looking for?I have a Python Function App on the Flex Consumption plan whose deployed package (released-package.zip) is repeatedly being overwritten with an outdated version approximately every 20-40 minutes, with no corresponding deployment event anywhere I can find.

Environment:

Function App: analytics-ingest (Linux, Python 3.11, Flex Consumption)
Deployment storage: defaultresourcegrou990e / container app-package-analytics-ingest-d0bd37e
Deployed via GitHub Actions using Azure/functions-action@v1

Symptom: A specific file inside my deployed function (function.json, containing a timer trigger schedule) keeps reverting from my intended hourly schedule back to an old daily schedule. I've confirmed this by checking the Last Modified timestamp on released-package.zip directly via az storage blob show, and it changes repeatedly without any new GitHub Actions run in my repo's history.

What I've ruled out:

No new GitHub Actions workflow run occurs when the revert happens (confirmed via Actions history)
Not caused by any local script/cron/LaunchAgent on my own machine (checked directly)
Not related to Azure Cloud Shell (confirmed ephemeral, doesn't retain state between sessions)
Removing remote-build: true from the deployment workflow did not stop it (reverted again 12 minutes after a clean redeploy without that flag)
No Automation Accounts or Logic Apps exist in this subscription

Evidence gathered: I enabled StorageWrite diagnostic logging on the storage account and confirmed writes to this container are made using the Function App's own managed identity (App ID f511c258-d644-492f-9de3-6de829abf656), from internal Azure IP addresses (172.24.x.x range), with kudu as the user agent — but I haven't yet captured the exact write event that causes the revert (only the writes from my own manual redeployments so far).

Question: Is there any known Flex Consumption platform behavior — related to rolling updates, instance specialization, or package caching — that could cause the deployed package to periodically revert to a previous version without an explicit deployment? Or is this indicative of something else I should be looking for?

0 comments

2 answers

Your answer

Answer 1

I think Flex Consumption does not replace a deployed ZIP on its own, and what you can check is the blob’s write timestamp and the identity that performed the write. When the writer is the app’s managed identity and the user‑agent is kudu, it shows that a deployment call occurred outside the normal Flex runtime. Flex scale‑out or specialization does not rewrite released‑package.zip, so the next step is to look for any remaining deployment source that may still be invoking OneDeploy, such as Deployment Center, ARM/Bicep/Terraform pipelines, or other automation that could be redeploying an older package.

Answer 2

Hi Ari,

I would not expect normal Flex Consumption scale-out, rolling updates, or instance specialization to overwrite released-package.zip with an older package. In Flex Consumption, the app runs from a zip package stored in the configured deployment container, and deployments use One Deploy. The platform should read/mount the package, not periodically replace it with an older one just because instances are starting. Microsoft docs also note that the Azure Functions GitHub Action uses One Deploy when it detects a Flex Consumption app.

The fact that storage logs show writes from kudu is important. For Flex Consumption, Kudu/One Deploy is part of the deployment path, so that still points to some deployment/sync path being invoked, even if it is not coming from the GitHub workflow you are checking.

I would check these next:

In the Function App, go to Diagnose and solve problems and search for Flex Consumption Deployment. Microsoft documents this diagnostic tool for Flex Consumption deployment history, package status, and troubleshooting details.
Check whether the app has any configured source control / Deployment Center link still active:

az functionapp deployment

Check Activity Log around the overwrite time for any Microsoft.Web/sites/extensions/write, Microsoft.Web/sites/config/write, or deployment-related operation.
Review any IaC pipeline, Bicep/ARM/Terraform deployment, or environment promotion pipeline that may still reference an old package URI. Flex Consumption can also deploy code through ARM/Bicep using the /onedeploy extension/package source, so an infrastructure deployment could redeploy an older zip even if GitHub Actions did not run.
Enable blob versioning temporarily on the deployment storage account. That will let you compare the old/new released-package.zip versions and recover the package if it gets overwritten again.
Rotate/regenerate the Function App publish profile or credentials if any old deployment process may still have access.

In short, this does not look like expected Flex Consumption runtime behavior. It looks more like another deployment mechanism is still writing to the deployment container. If the Flex Consumption Deployment diagnostic tool does not show the source, I would open a Microsoft support case with the storage write event time, blob version/ETag, Function App name, region, and the Kudu user-agent details.