Repository navigation
Description
When loading a browser test suite, the runner applies a load timeout of max(30s, ). This is derived from the per-test timeout and cannot be configured independently or disabled. Notably, the existing suite_load_timeout config option — which looks like it's meant for exactly this — has no effect on the browser load path.
I'd like the browser suite-load timeout to honor suite_load_timeout (including none to disable), decoupled from the per-test timeout.
What the code does today (on master, test 1.31.x / test_core 0.6.19)
BrowserPlatform.load computes its own timeout from metadata.timeout (the test timeout), floored at 30s:
// pkgs/test/lib/src/runner/browser/platform.dart, BrowserPlatform.load
var timeout = const Duration(seconds: 30);
if (suiteConfig.metadata.timeout.apply(timeout) case final suiteTimeout?
when suiteTimeout > timeout) {
timeout = suiteTimeout;
}
var suite = await browserManager.load(path, suiteUrl, suiteConfig, message, platform.compiler, mapper: ..., timeout: timeout);That timeout is what produces LoadException('Timed out waiting for browser to load test suite. ...') in
BrowserManager.load. Consequences:
- The floor is 30s. Even with timeout: none, Timeout.none.apply(30s) returns null, so the load timeout stays 30s.
- The only way to raise the browser load timeout is to raise the per-test timeout — which also raises it for every
actual test body.
Meanwhile, suite_load_timeout (added in test_core 0.6.16, parsed in configuration/load.dart as
_parseValue('suite_load_timeout', Timeout.parse)) is only applied to the outer LoadSuite test in load_suite.dart:
LocalTest(name, Metadata(timeout: config.suiteLoadTimeout), body),
Since it defaults to Timeout.none and the inner browser load timeout (# 1 above) fires first at 30s, suite_load_timeout never governs the browser "waiting for browser to load test suite" case. Setting it — to none or anything else — does not change that failure.
Why this matters to me
We're migrating a large codebase to Dart 3 and hitting these load timeouts across several packages. Controlling the load timeout via the test timeout is a poor fit:
- Slow failure. After extending our per-test timeout, when actual failures occur we frequently see time outs on the order of minutes. Which makes our ci slower and more painful in a failure case.
- Loss of a real safety net. Raising timeout to give loading more headroom also removes the per-test guard, so a
mistaken/runaway test can now run for that whole inflated duration. - The value is opaque and environment-sensitive. 30s isn't documented as the load floor, and the right value differs by machine and compiler target (dart2js-release vs DDC, fast laptop vs CI VM). It's a fixed wall-clock floor, so there's no single good number.
The Request
- Honor suite_load_timeout on the browser platform. Have BrowserPlatform.load use suiteConfig.suiteLoadTimeout instead of metadata.timeout, so the option added for this purpose actually reaches the browser load path. Respect Timeout.none to disable the load timeout entirely.
- Don't force the 30s floor when the load timeout is set explicitly. The max(30s, …) floor should apply to the default only, not override an explicit suite_load_timeout.
Activity
Yusufihsangorgel commentedon Aug 12, 2026
@natebosch an unset
suite_load_timeoutcomes back asTimeout.none, so should the browser load keep 30 seconds as its default and honor the option only when it is set explicitly, or just take the option's value and lose the floor you added in #2080?dustyholmes-wf commentedon Oct 8, 2026
This continues to pop up as packages only ever seem to get bigger. Our only recourse is to change the test timeout to a number larger than 30s. This is not ideal.