Fix Blazor Wasm and disable Ntex Fortunes in CI

[LoopedBard3]

Both Blazor Wasm and Ntex Fortunes have been failing in benchmarks-ci-02 since mid‑April. The last green run was 20260326.1 on Mar 26; every run since has failed on a docker build --pull for one of these two scenarios. Both come from upstream dockerfiles outside this repo that have rolled forward in incompatible ways. Take a different approach for each.

Investigation

Reproduced both failing crank commands from build 2974764 on Docker Desktop:

• Blazor Wasm → docker build --pull --build-arg gitBranch=main -t benchmarks_dockerfile -f src/Components/benchmarkapps/Wasm.Performance/dockerfile .../src/Components/benchmarkapps/Wasm.Performance (log)
• Ntex Fortunes → docker build --pull -t benchmarks_ntex-db -f frameworks/Rust/ntex/ntex-db.dockerfile .../frameworks/Rust/ntex/ (log)

Blazor Wasm

dotnet/aspnetcore's wasm dockerfile installs Node.js 21 via https://deb.nodesource.com/setup_21.x. Node 21 went EOL in June 2024 and recent aspnetcore npm dependencies require node 18 || 20 || >=22:

npm WARN EBADENGINE Unsupported engine { package: 'balanced-match@4.0.4', required: { node: '18 || 20 || >=22' }, current: { node: 'v21.7.3', npm: '10.5.0' } }
npm WARN EBADENGINE Unsupported engine { package: 'brace-expansion@5.0.5', ... }
...
[!] Error: require() of ES Module /src/node_modules/@tootallnate/once/dist/index.js from /src/node_modules/http-proxy-agent/dist/agent.js not supported.
Error [ERR_REQUIRE_ESM]: ...
npm ERR! Lifecycle script `build:debug` failed with error

Ntex Fortunes

TechEmpower's frameworks/Rust/ntex/Cargo.toml uses ntex-bytes = { version = "1.5", features=["simd"] } — caret semver, so cargo resolves to the newest 1.x. ntex-bytes 1.6.0 shipped 2026-05-02 and introduced the BytePages type, which the fafhrd91/postgres ntex-3 tokio-postgres fork (frozen at fbc7a17) does not understand — it still uses BytesMut. The workspace builds tokio-postgres for every binary when --features=tokio is set, so the ntex-db image cannot be produced:

error[E0308]: mismatched types
   --> /usr/local/cargo/git/checkouts/postgres-.../tokio-postgres/src/query.rs:77:52
   |
77 |             encode_bind(statement, params, "", buf)?;
   |             -----------                        ^^^ expected `&mut BytesMut`, found `&mut BytePages`
error: could not compile `tokio-postgres` (lib) due to 9 previous errors

Fix

Blazor Wasm — short-term local workaround under docker/wasm-performance/: copy of upstream's dockerfile, exec.sh, and a new benchmarks.compose.json, with setup_21.x → setup_22.x and the source repo pointing at this repo so crank picks up the override. build/job-variables.yml now points blazorWasmJobs at the local compose JSON.

A real upstream fix is in flight: dotnet/aspnetcore#66686. Once that merges, drop docker/wasm-performance/ and revert build/job-variables.yml back to the upstream config URL.

Ntex Fortunes — disable. TechEmpower/FrameworkBenchmarks is now archived (last push 2026‑03‑24), so a real upstream fix is not coming. Comment out the Ntex Fortunes entry in the two places it runs:

• build/frameworks-database-scenarios.yml
• build/containers-scenarios.yml

Each disable carries a comment explaining the failure mode and pointing at the other site, so it's easy to re-enable as a pair if someone forks/pins the ntex source back into a working state. Ntex Plaintext and Ntex Json continue to run; their binaries don't link tokio-postgres, so the ntex-plt build is unaffected.

Verification

Ran the exact crank docker build --pull invocation locally on Docker Desktop, fetching source from the same dotnet/aspnetcore main commit (29e4b0d3):

Dockerfile	Result
dotnet/aspnetcore main (setup_21.x) — control	❌ fails at RUN npm run build with the ERR_REQUIRE_ESM shown above
docker/wasm-performance/dockerfile (this PR, setup_22.x)	✅ npm run build succeeds, publishes Wasm.Performance.Driver, final playwright image is produced
same fix on the upstream branch LoopedBard3/aspnetcore:loopedbard3/wasm-perf-node22	✅ identical end-to-end success

[LoopedBard3]

Closing to re-open with only the ntex disable scoped in; the Wasm.Performance workaround stays local to LoopedBard3/Benchmarks while dotnet/aspnetcore#66686 lands the upstream fix.