Azure App-Service Swap "Bounces" Between Source and Destination

Question

I'm seeing some interesting behavior on Azure App Service that I'm hoping somebody will be kind enough to comment on.

Reproduction steps (all Azure steps can be done in the portal):

• Create a new Web App in App Service (Standard pricing level, single instance is fine), e.g. mysite
• Create a new staging slot for that App, e.g. mysite-staging
• Deploy a bare-bones ASP.NET app to mysite with a file /scripts/test.js that has the content //ONE
• Deploy a bare-bones ASP.NET app to mysite-staging with a file /scripts/test.js that has the content //TWO
• Swap the deployment slots
• Immediately after the swap starts, navigate to mysite.azurewebsites.net/scripts/test.js and monitor the returned content during the swap operation (by continually doing a force-refresh in the browser)

What I would expect to see:

• At some point during the swap, the content changes seamlessly/consistently/irreversibly from //ONE to //TWO

What I actually see:

• During the swap operation, the content "flickers"/"bounces" between //ONE and //TWO. After the swap operation is complete, the behavior is stable and //TWO is consistently returned

The observed behavior suggests that there is no single point in time at which all traffic can be said to be going to the new version.

The reason this concerns me is the following scenario:

• A user requests a page mysite.azurewebsites.net which, during this "bouncing" stage, responds with the "v2" version of the page with a link to a CDN-hosted script mycdn.com/scripts/test.js?v2 (the ?v2 is a new query string)
• The browser requests the script from the CDN, which in turn requests the script from mysite.azurewebsites.net. This time, the "bouncing" causes the response to be the v1 version of the script.
• Now we have a v1 version of the script cached in the CDN, which all users in that region will load with the v2 version of the page

My question: Is this "bouncing" behavior during a swap operation "by design"? If so, what is the recommended approach for solving the pathological case above?

Answer 1

The behavior you've described is currently by design. When we perform the swap we update the mappings between hostnames and the sites in our database but our frontend instances cache those mappings and refresh them every 30 seconds. So the "bouncing" period may last up to 30 seconds.

I do not have at the moment a good recommendation on how to solve the case, but will look into possible ways to address this.