hdrgen hangs during merge on Windows (WebView2); every other host passes

[adulbrich]

Symptom

The desktop pipeline reaches the merge stage and stops. On a GitHub windows-latest runner, with a ten-minute budget:

19:20:50  Processing set 1 of 1: ...\e2e-tests\test\inputs\JPEG
19:21:23  Merging exposures
19:21:28  Filtering images: kept 13 of 18
          (nothing further for 600 s)

No crash, no exception, no out-of-memory, no error toast, and nothing waiting on a dialog. The webview reports tauri=true workers=true. It simply never returns.

Filtering is reported from inside the merge stage, so what has hung is hdrgen itself, on 13 JPEG frames.

What is not the cause

Each of these was checked rather than assumed:

• Not slowness. The budget was raised from 180 s to 600 s and the stall point did not move. The same bracket takes ~24 s on macOS and passes comfortably on Ubuntu.
• Not a blocked dialog. The run-confirmation is answered, and the failure report explicitly looks for a dialog offering a decision. None is present.
• Not the Web Worker. workers=true, and the worker got far enough to report filtering results back to the page.
• Not a Tauri IPC failure. tauri=true, and the earlier stages read their input files successfully.

Where it does work

Host	Engine	Result
macOS desktop	WKWebView	passes, ~1m42s for the whole suite
Ubuntu desktop	WebKitGTK	passes in CI
Browser (WebKit)	WebKit	passes in CI
Browser (Chromium)	Chromium	passes in CI
Windows desktop	WebView2	hangs

Windows is the only failing host, and WebView2 is the only engine not otherwise represented. That is the odd part: WebView2 is Chromium, and Chromium passes in the browser suite. So it is not simply "Chromium cannot run this".

Why this was not noticed sooner

The e2e-tests job carried continue-on-error: true, so the workflow reported success with two failing jobs. This case has never passed on Windows; the recent CI rework removed the flag, which is what made it visible.

The open question, and it matters

Is this specific to a two-core CI runner, or does it affect real Windows users?

Nothing here distinguishes them. The desktop app ships a Windows installer, so "hdrgen hangs" would be severe rather than cosmetic. This needs someone to run a JPEG bracket through the app on a real Windows machine before the next release.

Suggested next steps

1. Run the reference JPEG bracket on real Windows hardware. If it completes, this is a runner artefact and the CI case can be scoped accordingly.
2. If it reproduces, instrument hdrgen's wasm entry: log around callMain, and record the heap size at the point of the stall. The wasm32 ceiling and its ~1.6 GB floor at ~70 bytes/pixel are documented in Epic: port the pipeline to WebAssembly for a zero-dependency desktop app and a fully client-side web app #227.
3. Worth ruling out Windows Defender scanning the wasm heap growth, which is pathological on GitHub runners.

[adulbrich]

The hang did not reproduce on CI today, and there is new evidence that reframes this issue's central question.

What happened

PR #249 (branch opfs-raw-cache) ran the full desktop suite on the same windows-latest runner configuration this issue describes:

End-to-end (windows-latest)   pass   5m55s

app.e2e.ts completed, including generates an HDR image — the merge stage this issue says stalls indefinitely. Two separate runs on that branch, both green. Nothing in that PR touches hdrgen, the merge stage, or the WebAssembly pipeline; it adds a RAW-conversion cache that a JPEG bracket never reaches.

Why that is worth acting on rather than closing

This issue rules out slowness with:

Not slowness. The budget was raised from 180 s to 600 s and the stall point did not move. The same bracket takes ~24 s on macOS and passes comfortably on Ubuntu.

That premise now has a counterexample. On 2026-07-31 the same reference JPEG bracket was measured on macOS taking 11 m 35 s in the merge stage alone — roughly 29x the ~24 s baseline this issue cites — on a machine that turned out to be under severe memory pressure (~137 MB free of 16 GB, 88 million pageins). The pipeline is documented to peak near 2.13 GB in hdrgen, so a host that cannot supply that thrashes rather than runs.

On a two-core CI runner with less RAM, the same effect would comfortably exceed a 600 s budget and present exactly as this issue describes: no crash, no exception, no OOM message, nothing waiting on a dialog. A slow-enough merge and a hang are indistinguishable from the outside.

A related trap, documented while investigating #243

In that same session, an OPFS write of 67 MB failed on WebKit with UnknownError: ... out of memory, which looked like a browser storage limit. A throwaway 4-byte control write then failed identically — the host was out of memory, not the browser incapable. The probe added in PR #249 now performs a tiny control operation first and reports a run inconclusive when it fails, precisely so resource exhaustion is not mistaken for a platform defect.

This issue may be the same mistake in a different costume.

Suggested next step

Before treating this as a WebView2 defect, instrument the Windows job for memory: log available memory and page-fault counts at the merge stage, and log hdrgen's peak wasm heap (onHeapPeak already reports it). If the runner is thrashing, this is a resource issue and the fix is bounding memory, not chasing WebView2. If memory is comfortable and it still never returns, that is a genuine hang and this issue stands as written — but with the slowness explanation properly eliminated rather than assumed.

Worth also noting: continue-on-error: true is gone from that job, so a regression here now fails the build rather than reporting green.