[sarah (satvu)]

Issue describing the changes in this PR

Resolves #5465

Leverage defaultHostName instead of .FirstOrDefault() of enabledHostNames property to make sure check goes to the correct site.

Pull request checklist

• My changes do not require documentation changes
  • Otherwise: Documentation issue linked to PR
• My changes do not need to be backported to a previous version
  • Otherwise: Backport tracked by issue/PR #issue_or_pr
• My changes should not be added to the release notes for the next release
  • [] Otherwise: I've added my notes to release_notes.md
• I have added all required tests (Unit tests, E2E tests)

Additional Information

Went back through the history w/ an agent, the use of enabledHostNames goes all the way to "day one" and has no documented reasoning for why. One potential reason that enabledHostNames is used is because it only lists hostnames that are currently enabled/accessible, because defaultHostName exists even if the site is stopped or hostname is disabled.

That still seems incorrect to me. Using defaultHostName should be more reliable because it returns the canonical *.azurewebsites.net hostname, avoiding issues with custom domains in enabledHostNames that might have different TLS/routing configurations.

Example of what is returned from each:

{
"defaultHostName": "some-app-name.azurewebsites.net",
"enabledHostNames": [
"some-custom-domain-name.net",
"some-app-name.azurewebsites.net",
"some-app-name.scm.azurewebsites.net"
]
}

Testing

• Tested locally e2e, deployed flex app and checked that health check logs were written and check succeeded.