Azure Functions host 4.1052.300.26370 breaks Node worker startup — globalThis.crypto not defined

Question

Azure Functions host 4.1052.300.26370 breaks Node worker startup — globalThis.crypto not defined

Scott Siegel 5

Host rollout 4.1052.200.26352 → 4.1052.300.26370 stopped exposing globalThis.crypto to the Node language worker. Every function fails at worker load with ReferenceError: crypto is not defined (thrown from randomUUID() in @azure/data-tables / @typespec/ts-http-runtime at module-import time), so the entire worker process can't start.

Environment: Node 20, Linux, Flex Consumption plan, Central US region.

Impact: Production down. Onset 2026-08-05 00:43:22 UTC, zero occurrences before that timestamp. 37+ Function Apps affected, blast radius still growing.

Evidence this is host-caused, not app-caused: both host versions are running concurrently on the same apps, same deployed package, same host.json, same extension bundle, same Node version. Exception attribution over 6h:

4.1052.200.26352 (old): 10,965 exceptions, 0 crypto failures
4.1052.300.0: 2,413 exceptions, 0 crypto failures
4.1051.300.26316: 4 exceptions, 0 crypto failures
4.1052.300.26370 (new): 536,472 exceptions, 564,821 crypto failures

Nothing was deployed on our side at onset.

Questions:

Is this a known regression tied to the Node 20 EOL rollout?
Is there a supported way to pin Flex Consumption apps to the prior host version? (FUNCTIONS_EXTENSION_VERSION isn't supported on Flex Consumption, and linuxFxVersion pinning isn't available there either as far as we can tell.)
Is there an ETA for a fix or rollback?

We're on a Basic support plan currently, so unable to open a formal technical ticket — posting here as the available channel.

Gursimran Singh 495 Reputation points Microsoft External Staff Moderator

2026-08-05T17:41:46.8333333+00:00

Hi @Scott Siegel ,

Welcome to the Microsoft Q&A Platform! Thank you for asking your question here.

The evidence shared points to a runtime/host-level issue rather than an application change. Since no deployment occurred on your side and the failures are isolated to host version 4.1052.300.26370, the host rollout is currently the strongest common factor. I could not find any public documentation confirming a known regression related to globalThis.crypto or the Node 20 transition, nor any published mechanism to pin Flex Consumption apps to a previous host build. If other customers observe the same behavior on the same host version, that would further support a platform-side regression investigation.

2 answers

Your answer

Gursimran Singh 495 Reputation points Microsoft External Staff Moderator

2026-08-05T17:41:46.8333333+00:00

Hi @Scott Siegel ,

Welcome to the Microsoft Q&A Platform! Thank you for asking your question here.

The evidence shared points to a runtime/host-level issue rather than an application change. Since no deployment occurred on your side and the failures are isolated to host version 4.1052.300.26370, the host rollout is currently the strongest common factor. I could not find any public documentation confirming a known regression related to globalThis.crypto or the Node 20 transition, nor any published mechanism to pin Flex Consumption apps to a previous host build. If other customers observe the same behavior on the same host version, that would further support a platform-side regression investigation.

Answer 1

Thanks Vincentius.

@Gursimran Singh — appending more precise evidence in case it helps a platform-side investigation, and also closing out this thread since we've resolved it on our end.

More specific correlate than the host version alone: within host 4.1052.300.26370, the failure was isolated to instances that came up running Node 18, even though our Function Apps explicitly declare node|20 in functionAppConfig.runtime. In the same window, 942 Node-20 worker starts on the identical deployed package had zero errors, while 187 Node-18 worker starts all failed identically at load with crypto is not defined (thrown from randomUUID() at module-import time in @azure/data-tables → @typespec/ts-http-runtime — Node 18 doesn't expose globalThis.crypto, Node 20+ does). So the rollout appears to have started some workers on a Node major the app never requested, and any app depending on globalThis.crypto at import time would hit this the same way.

For anyone else who lands here: we didn't wait on a host-side fix. We migrated our Function Apps from Node 20 → Node 22 (Node 20 was already EOL as of 2026-04-30), which sidesteps the mismatch regardless of which host version an instance lands on. Recovered ~3 hours after onset. Confirmed, as you and others noted, that Flex Consumption doesn't support FUNCTIONS_EXTENSION_VERSION or linuxFxVersion pinning — upgrading past the runtime version at risk was the only real lever, not a platform-side wait.

Answer 2

hi @Scott Siegel based on the information you've shared, this does appear to be consistent with a runtime or host regression rather than an application change, especially since the same deployment is behaving differently across host versions and no changes were made on your side.

For Azure Functions Flex Consumption, there isn't a supported way to pin the runtime host to a previous build. The platform manages host updates automatically, and options such as FUNCTIONS_EXTENSION_VERSION or linuxFxVersion pinning aren't available in the same way as other hosting plans. Microsoft recommends running on the supported v4 runtime, while the underlying host version is platform-managed. :contentReference[oaicite:1]{index=1}

Given the production impact and the evidence you've collected, I recommend waiting for a Microsoft engineer or moderator to investigate whether this is a known regression. Your comparison across host versions should help the product team identify the issue more quickly.

I hope this helps.