Container panic 'Could not find file /home/site/wwwroot/output.tar.gz' on appsvc/python:3.11_20260203.2.tuxprod

[nxfwapd]

Summary

Azure App Service Linux Python 3.11 deploys are failing at container start because the build phase produces output.tar.zst while the runtime PythonStartupScriptGenerator looks for output.tar.gz and panics.

Environment

• Image tag: appsvc/python:3.11_20260203.2.tuxprod
• Oryx version (per build log): 0.2.20251017.2
• Deploy method: GitHub Actions OIDC -> OneDeploy (zip)
• Date observed: 2026-05-08 / 2026-05-09 (UTC)
• Customer App Service name (for cross-reference): wapd-image-finder

Symptoms

1. GitHub Actions build step succeeds.
2. OneDeploy returns HTTP 200.
3. Container never serves traffic.
4. /home/LogFiles/<latest>_docker.log shows:

   panic: Could not find file /home/site/wwwroot/output.tar.gz
   

5. oryx-manifest.toml written by the build phase references output.tar.zst (zstd-compressed), not output.tar.gz.

Apparent root cause

A mismatch between the build-time compression format (zstd) and the runtime extractor's expected format (gzip). The PythonStartupScriptGenerator in this image tag does not appear to handle .tar.zst artifacts.

Workaround being tested

Setting COMPRESS_DESTINATION_DIR=false as an app setting (folk wisdom — not officially documented as controlling format selection). Results pending; will update.

Ask

• Confirmation whether this is a known regression in 3.11_20260203.2.tuxprod.
• Documented env var or version pin to roll back to a known-good earlier image while a fix lands.
• Whether PythonStartupScriptGenerator in this image is intended to support zstd artifacts (and is broken), or whether the build-phase format selection is wrong.

[nxfwapd]

Confirmed workaround

Setting App Service app setting COMPRESS_DESTINATION_DIR=false on wapd-image-finder and redeploying restored the container to a healthy state.

Reproduction details

• Image tag where reproduced (today): appsvc/python:3.11_20251017.2.tuxprod
• Exact runtime error:

  Oryx Version: 0.2.20251017.2, Commit: 482d4c55e818733ab33b9d2131f9dc485a21fd03
  Output is compressed. Extracting it...
  panic: Could not find file '/home/site/wwwroot/output.tar.gz'
  

• The build phase produced output.tar.zst per the manifest; the runtime PythonStartupScriptGenerator only knows how to extract .tar.gz.

Build path that works (with the workaround)

GitHub Actions azure/webapps-deploy@v3 -> OneDeploy with both:

• COMPRESS_DESTINATION_DIR=false
• SCM_DO_BUILD_DURING_DEPLOYMENT=true

With these set, Oryx skips the zstd compression step at build time, the runtime extractor has nothing to extract, and the container starts cleanly.

Build path that does NOT work

az webapp deploy --type zip direct from local. This bypasses the Oryx build phase entirely, leaves the deploy with no oryx-manifest.toml, no antenv virtualenv, and the runtime startup script can't cd into the source tree. Result: WARNING: Could not find virtual environment directory /home/site/wwwroot/antenv followed by cd: can't cd to backend. So the workaround only applies to deploy paths that DO trigger Oryx build.

Ask reiterated

• Can PythonStartupScriptGenerator in the 3.11_20251017.x image be patched to handle .tar.zst (or to fall back to .tar.zst when .tar.gz isn't found)? That would be a forward-compatible fix that doesn't require every Python customer to set this env var.
• Alternatively, document COMPRESS_DESTINATION_DIR=false as the official workaround in the Linux Python troubleshooting docs while a code fix lands.

Filing this as confirmed-workaround data; happy to provide additional logs if useful.

[Micatio]

What's the status with this? COMPRESS_DESTINATION_DIR=false should support the option to uncompress files instead of Oryx creating a zip (zst).
This causes the whole process to fail as the startup command isnt found.

Update: in my instance, I was attempting to reference a script in the www folder. Obviously, the zst is extracted to a temporary folder

[Saipriya-1144]

The compression step exists to optimize deployment and cold-start times. We transitioned the default compression format from zstd to gzip, and our current runtime images are capable of extracting both formats.

The failure you encountered was the result of a narrow edge case. Under certain conditions, the application fell back to an older runtime image which was built before zstd support and therefore did not recognize the .tar.zst  artifact produced at build time.

The fix has now been rolled out, and this corner case should no longer occur