Site name: keen-kringle-7a5bf6 (custom domain tuvisaaustraliana.com)
Site ID: 1d3bbd47-48f8-4165-988c-7af0fe15ab16
Our site is serving stale content for /es/, /en/, and /zh/ despite multiple successful production deploys containing the correct, updated content (a fix to our contact form’s data-netlify attribute).
Deploy IDs affected: 6a5bcb2b88372c3a9ad45fb3, 6a5bcc726054d3411c813d89, 6a5bce628df1ec495f463fb0, 6a5bcfdd4d50018c474f57b4, 6a5bd1636657f1547ab5dde4 (uploaded via the raw zip Deploy API instead of the CLI, to rule out a CLI-side bug — same result), and 6a5c49d43522c97558c84eed.
Each deploy reaches state: ready and becomes published_deploy.id, and each deploy’s summary reports “All files already uploaded by a previous deploy with the same commits” (0 files transferred).
We have proven the deploy’s own stored content IS correct: downloading the file directly via the dashboard’s per-deploy file browser (Deploys → [deploy] → Options → Download deployed files) returns the correct, updated bytes, and that same deploy’s own Post-processing log shows our Forms correctly detected with the updated field set.
However, requesting the live page — including that exact deploy’s own unique immutable *.netlify.app subdomain URL — returns different, older bytes, with cache-status: fwd=miss (a genuine origin miss, not an edge cache hit). This rules out edge-CDN caching and points to a bug in how the serving layer resolves which stored blob to return for these paths.
We’ve also ruled out: local CLI cache, _redirects misrouting, split-testing/branch-deploy aliasing, deploy locking, slow CDN propagation, and any client-side proxy/cache. Netlify’s own status page showed All Systems Operational at the time.
Please investigate why the CDN/serving layer is not returning the content that the deploy’s own storage and post-processing pipeline confirm is correct. Happy to provide any further diagnostic info (curl -v output, deploy logs, etc.) on request.