Skip to content

Browser suite-load timeout is tied to the test timeout (min 30s) and ignores suite_load_timeout; no way to raise or disable it independently #2691

Closed

Description

@dustyholmes-wf

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:

  1. 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.
  2. 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.
  3. 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

  1. 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.
  2. 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

  1. Yusufihsangorgel commented on Aug 12, 2026

    @Yusufihsangorgel
    Contributor

    @natebosch an unset suite_load_timeout comes back as Timeout.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?

  2. dustyholmes-wf commented on Oct 8, 2026

    @dustyholmes-wf
    Author

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions