CODEWITHSUNDEEP
azureazure-web-app-service
Tom
Tom

Reputation: 377

Stale WEBSITE_HOSTNAME value on app service after swap

I have an Azure App Service with production and staging slots. I'm running a couple of websites using virtual directories. I have tasks setup to notify me when each website has been warmed up. I'm using the WEBSITE_HOSTNAME environment variable to determine where the email is being generated and appending Prod/Staging to the subject. I also have the assembly version in the body to see what code is being warmed up.

string websiteHostName = Environment.GetEnvironmentVariable("WEBSITE_HOSTNAME");

When I deploy 'Version 2' to staging I get the emails with '/staging' appended correctly and 'Version 2' in the body. When I swap the slots I get emails with '/prod' and 'Version 1' in the body.

When I check KUDU for the production slot the WEBSITE_HOSTNAME is (site name)-staging.azurewebsites.net and the value for the staging slot is (site name).azurewebsites.net. If I manually restart the staging slot the WEBSITE_HOSTNAME value gets updated to -staging.azurewebsites.net and the email I receive from the warm up process has '/staging' and 'Version 1' which is what I would expect from the warm up process when it is swapped to staging.

I have already tried using deployment slots but the swap didn't work correctly as the swap was being marked as completed before the app had warmed up completely and this caused downtime for the users.

What is the reason for the restart of the production slot when it is swapped to staging? Should the WEBSITE_HOSTNAME value be updated when this happens? I'm confused since a manual restart updates the value.

Is there a way to prevent the app from restarting when it gets swapped to staging?

Alternatively, is there a way to get the HTTP_HOST variable value?

Upvotes: 3

Views: 1806

Answers (1)

DashleenBhandari-MSFT
DashleenBhandari-MSFT

Reputation: 651

The incorrect WEBSITE_HOSTNAME after swapped is a known issue and we are working on resolving it. Workaround is to restart which is not perfect. Another workaround is for app to ignore that environment variable and rely on the actual incoming header HTTP_HOST.

Upvotes: 2

Related Questions