AZFD0010 timezone diagnostic never fires on Linux Consumption apps hosted on Legion

[kshyju]

Summary

The AZFD0010 diagnostic event that warns customers about the unsupported TZ / WEBSITE_TIME_ZONE app settings on Linux Consumption is unreachable for Linux Consumption apps hosted on Legion. The guard is scoped to the legacy Atlas/ACI hosting mode only, so after the Linux Consumption migration to Legion the warning silently stopped firing for the affected population.

Related: #9203 (the original bug), #9662 (the PR that added the diagnostic).

Current behavior

WebJobsScriptHostService.ValidateLinuxSKUConfiguration is the only place AZFD0010 is emitted:

azure-functions-host/src/WebJobs.Script.WebHost/WebJobsScriptHostService.cs

Lines 292 to 307 in d3dd29e

	var functionsTimeZone = _environment.GetEnvironmentVariable(EnvironmentSettingNames.FunctionsTimeZone);
	var functionsWebsiteTimeZone = _environment.GetEnvironmentVariable(EnvironmentSettingNames.FunctionsWebsiteTimeZone);
	// If we have a linux consumption app and the time zone env variable is set, log a warning and diagnostic event
	if (_environment.IsLinuxConsumptionOnAtlas() &&
	(!string.IsNullOrEmpty(functionsTimeZone) ||
	!string.IsNullOrEmpty(functionsWebsiteTimeZone)))
	{
	string message = Script.Properties.Resources.LinuxConsumptionRemoveTimeZone;
	// Log diagnostic event
	logger?.LogDiagnosticEventError(DiagnosticEventConstants.LinuxConsumptionTimeZoneErrorCode, message, DiagnosticEventConstants.LinuxConsumptionTimeZoneErrorHelpLink, new InvalidOperationException(message));
	// Log warning so this message goes to App insights
	logger?.LogWarning(message);
	}

Why it can never fire on Legion

The two hosting-mode predicates in EnvironmentExtensions are mutually exclusive by construction on LEGION_SERVICE_HOST:

public static bool IsLinuxConsumptionOnAtlas(this IEnvironment environment)
{
    return !environment.IsAppService()
        && !string.IsNullOrEmpty(environment.GetEnvironmentVariable(ContainerName))
        && string.IsNullOrEmpty(environment.GetEnvironmentVariable(LegionServiceHost));   // must be EMPTY
}

public static bool IsConsumptionOnLegion(this IEnvironment environment)
{
    return !environment.IsAppService()
        && (...)
        && !string.IsNullOrEmpty(environment.GetEnvironmentVariable(LegionServiceHost));  // must be NON-EMPTY
}

On Legion, LEGION_SERVICE_HOST is set, so IsLinuxConsumptionOnAtlas() returns false and the block is dead code.

Impact

The TZ / WEBSITE_TIME_ZONE misconfiguration is documented public behavior with severe, non-obvious consequences. From Timer trigger — NCRONTAB time zones:

WEBSITE_TIME_ZONE and TZ aren't currently supported when running on Linux in a Flex Consumption or Consumption plan. In this case, the setting WEBSITE_TIME_ZONE or TZ can create SSL-related issues and cause metrics to stop working for your app.

In practice the failure presents as:

Azure.RequestFailedException: The SSL connection could not be established, see inner exception.
 ---> System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
 ---> System.Security.Cryptography.CryptographicException: Error occurred during a cryptographic operation.
       at Interop.Crypto.X509StoreSetVerifyTime(SafeX509StoreHandle ctx, DateTime verifyTime)
       at System.Security.Cryptography.X509Certificates.OpenSslX509ChainProcessor.InitiateChain(...)
       at System.Net.Security.SslStream.VerifyRemoteCertificate(...)

This breaks all outbound HTTPS from the host process, so:

• every singleton/timer listener fails to start (timer functions never execute at all)
• SyncTriggers fails
• Application Insights receives no telemetry
• the azure.functions.webjobs.storage health check reports Unhealthy with the generic "Unable to access AzureWebJobsStorage" description

The failure is fully deterministic — every host instance for an affected app is impacted, and restarts do not help.

Because the symptom surfaces as a storage/TLS error rather than a configuration error, and because the diagnostic that would name the actual cause never fires, affected customers and support engineers reasonably conclude the storage account or networking is at fault. This has produced multi-week investigations chasing storage keys, TLS settings, firewall rules, and DNS — none of which are the cause. The diagnostic exists precisely to short-circuit that, and it is not reaching the affected population.