Can you shed some light on enviroments swap in Azure Static Web App?

Question

I wonder what happens behind the curtains when you promote a staging env in Azure Static Web App.

What I see when I promote a PR is GitHub Action rebuilding and redeploying the commit in the Production Env, while what I was expecting was something similar to Azure Web App slots swap, i.e. a DNS update rather than a full rebuild and redeploy.

I wonder what could happen if, while deploying the new commit (i.e. uploading the files), someone requests the web site (in my case a Blazor WASM app). Is it possible that the user gets a .js from the previous commit and a .css from the current one just because the new css has been already uploaded and the .js is not?

Answer 1

Thanks! Static Web App deployments are atomic and we won’t shift to serving the new content until it is readily available for all edge nodes that can serve it. There should never be a time where a user is getting files from different commits when requesting the files directly.

The one corner case to keep in mind is client-side caching. If you are using cache headers (by default they are enabled and set to cache for 30s before revalidating) then the browser may use cached versions of your content in combination with newly pushed content.

Hope this helps.