Steps to reproduce

Run a web test suite repeatedly:

flutter test --platform chrome

on a project with ~28 test files / 283 tests, headless (the default for flutter test).

I do not have a minimal reproduction — this is intermittent at a measured rate of 1 run in 27 on an otherwise idle machine (26 consecutive passes at 29–32s, then one run that produced no further output for 300s and was still wedged 14 minutes later). What I do have is a full forensic capture of a live wedged run, taken through Chrome's DevTools protocol before killing it. That is the report.

Expected results

Every suite loads and the run reaches a verdict.

Actual results

The run stops mid-suite and never continues. Last reporter lines:

00:06 +82: <app>/test/pages/a_test.dart: <some test>
00:07 +83: loading <app>/test/pages/b_test.dart

83 tests passed, 8 of 28 suites finished, and the 9th never produced a single event.

Everything is alive at 0% CPU — a deadlock, not a spin: the dartvm running flutter_tools.snapshot test --platform chrome, the frontend_server_aot compiler, Chrome plus its GPU/network/storage helpers and three renderers. The test HTTP server still answered HTTP 200, and Chrome's DevTools endpoint still answered. So the browser launched fine and had its debugging port.

Forensics from the live wedged run

Chrome exposed exactly one target, the package:test host page. Its single suite iframe was readyState: complete with 538 of 538 DDC modules loaded (requirejs registry: 0 pending, 538 defined). Nothing failed to download.

But the engine in that iframe never started:

flutterCanvasKitLoaded : [object Promise]   still PENDING (checked ~14 min in)
CanvasKitInit          : undefined
flutterCanvasKit       : undefined
flutter-view elements  : 0
_flutter.loader        : ["didCreateEngineInitializer"]      (still waiting)

canvaskit.js had already been fetched successfully. Resource timing in that frame:

name: .../canvaskit/chromium/canvaskit.js
initiatorType: script, transferSize: 86796, decodedBodySize: 86496
startTime: 36ms, responseEnd: 38ms, duration: 1ms

Re-fetching every CanvasKit asset from the wedged run's own server returned HTTP 200 in single-digit milliseconds. So the file downloaded; its script never defined CanvasKitInit; the promise waiting on it never resolved. There is also no surviving <script> tag whose src contains canvaskit in that document.

(I considered and disproved an AMD/UMD collision with the DDC require.js loader: define.amd is null in that frame, canvaskit.js contains no define.amd branch, and none of the 538 defined modules holds CanvasKit's factory.)

The decisive comparison

Chrome's stored console log shows every healthy suite following an identical sequence:

Starting suite .../X.html
Appended iframe with src .../X.html#...
Injecting <script> tag. Using callback.
registerExtension() ... warning
WARNING: Falling back to CPU-only rendering. Reason: webGLVersion is -1
Font manifest does not exist at `assets/FontManifest.json` - ignoring.
Connecting channel for suite .../X.html

For the wedged suite the sequence stops dead after registerExtension(). The CPU-fallback line never appears, the font-manifest line never appears, and Connecting channel never appears.

Counted over the whole run: 9 suites started, 8 connected, 8 CPU-fallback lines.

So the wedge is inside renderer initialisation, at exactly the point where every healthy suite reports falling back to CPU-only rendering. Headless flutter test runs Chromium with --disable-gpu, so webGLVersion is -1 and every suite takes that CPU-only path, which downloads the Chromium CanvasKit variant. Intermittently the download completes but the awaiting promise never resolves, Dart main() never runs, and the suite never opens its channel.

Why this hangs the whole run rather than failing one suite

Nothing above it has a timeout:

1. FlutterWebPlatform.load (flutter_web_platform.dart) ends with return await controller.suite;. That future completes only when the browser side connects. No timeout.
2. That call holds _suiteLock, a Pool(1) released only by the suite's onDone, so no later suite can start either.
3. flutter test therefore never reaches a verdict and never exits.

Even a per-suite timeout at (1) that failed the suite loudly would be a large improvement over an unbounded wait.

Environment

Chrome for Testing 145.0.7632.6, macOS 26.5.2 arm64, renderer canvaskit, compileTarget: dartdevc.

flutter doctor -v

[/] Flutter (Channel stable, 3.41.9, on macOS 26.5.2 25F84 darwin-arm64, locale en-US)
    - Flutter version 3.41.9 on channel stable at /opt/homebrew/share/flutter
    - Framework revision 00b0c91f06 (2026-04-29), Engine revision 42d3d75a56
    - Dart version 3.11.5, DevTools version 2.54.2
[/] Xcode - develop for iOS and macOS (Xcode 26.6)
[X] Chrome - develop for the web (no /Applications Chrome; CHROME_EXECUTABLE points at
    Chrome for Testing 145.0.7632.6)
[/] Network resources

Possibly related, filed at the same time: #192013 — a different, deterministic way for flutter test --platform chrome to hang with no verdict, in the browser launcher rather than the engine. Distinct root cause; both are unbounded waits on the path to loading a web test suite.