You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[dwds] WebkitDebugger.enable 5-second hardcoded timeout causes TimeoutException on large web apps #2883
Problem
In package:dwds/src/debugging/webkit_debugger.dart, WebkitDebugger.enable() has a hardcoded 5-second timeout on _wipDebugger.enable().
On large enterprise Flutter Web applications (with dozens of dependencies and heavy generated source maps), Chrome's remote debugging protocol (Debugger.enable) takes between 8–15 seconds to finish its initial source-map parse and handshake under normal CPU loads.
Because of the rigid 5-second limit, flutter run -d chrome crashes deterministically on startup with:
Failed to establish connection with the web debug service: TimeoutException after 0:00:05.000000: Future not completed #0 Future.timeout (dart:async/future_impl.dart) #1 WebkitDebugger.enable (package:dwds/src/debugging/webkit_debugger.dart:166:9)
**Before this version:**
In previous versions of DWDS (e.g. 25.x), enable() awaited _wipDebugger.enable() without a timeout, which allowed Chrome sufficient time to attach.
Thank you @nshahan for triaging this as P1 and linking #2747
To provide more context for @Markzipan:
Why 5 seconds is too aggressive in practice:
In enterprise-scale Flutter Web applications (which often contain 40+ packages and large source maps):
When Chrome receives the CDP command Debugger.enable, it must synchronously parse and index all loaded scripts and source maps.
On real developer workstations under normal load, this initial indexing step consistently takes 8 to 15 seconds.
Because the timeout is hardcoded to 5 seconds, each of the 3 retry attempts fails before Chrome can even finish its first parse, leading to a guaranteed TimeoutException.
Thank you @Markzipan and @nshahan for the quick response and for taking ownership of this!
Could you please link the SDK commit / PR here once it is ready so we can track its progress? Also, do you anticipate this fix being included in an upcoming stable patch or the next minor SDK release?
Happy to help test the build as soon as it's available.
Awesome news! Thank you @Markzipan for landing the fix in dart-lang/sdk (commit 20bae76).
I will monitor flutter/flutter#195932. As soon as that lands, I will test it on channel master with our app and confirm back here.
Getting a cherry-pick into stable would be amazing. Thank you!
Hey @Markzipan and @nshahan,
Thanks a ton for this!
I went through the new code in webkit_debugger.dart — handling it with the 3-minute window and Future.any is super neat, definitely way better and cleaner than just bumping the timer.
Tested it out on our project and it's working great now. Chrome connects right away on startup with zero timeout crashes.
Please go ahead with the cherry-pick to beta/stable whenever you can. It's going to save a lot of folks working on big web apps from this headache!
Really appreciate how fast you guys jumped on this and sorted it out. Thanks again!
Activity
nshahan commentedon Oct 28, 2026
The timeout was added in #2747
cc @Markzipan
Lalith2212 commentedon Oct 29, 2026
Thank you @nshahan for triaging this as P1 and linking #2747
To provide more context for @Markzipan:
Why 5 seconds is too aggressive in practice:
In enterprise-scale Flutter Web applications (which often contain 40+ packages and large source maps):
When Chrome receives the CDP command Debugger.enable, it must synchronously parse and index all loaded scripts and source maps.
On real developer workstations under normal load, this initial indexing step consistently takes 8 to 15 seconds.
Because the timeout is hardcoded to 5 seconds, each of the 3 retry attempts fails before Chrome can even finish its first parse, leading to a guaranteed TimeoutException.
Markzipan commentedon Oct 29, 2026
Thanks for isolating this @Lalith2212! We can land a fix on our end (as DWDS moved to our SDK somewhat recently).
Lalith2212 commentedon Oct 30, 2026
Thank you @Markzipan and @nshahan for the quick response and for taking ownership of this!
Could you please link the SDK commit / PR here once it is ready so we can track its progress? Also, do you anticipate this fix being included in an upcoming stable patch or the next minor SDK release?
Happy to help test the build as soon as it's available.
[dwds] Wait longer for Chrome to respond to Debugger.enable
Markzipan commentedon Nov 3, 2026
No worries - and sorry about the churn here. Can you check out
flutter channel masterafter this PR lands? flutter/flutter#195932If that works, I can try to get a cherrypick into beta/stable sooner.
It should have the timeout bug fixes.
Lalith2212 commentedon Nov 4, 2026
Awesome news! Thank you @Markzipan for landing the fix in
dart-lang/sdk(commit 20bae76).I will monitor flutter/flutter#195932. As soon as that lands, I will test it on
channel masterwith our app and confirm back here.Getting a cherry-pick into stable would be amazing. Thank you!
Lalith2212 commentedon Nov 4, 2026
Hey @Markzipan and @nshahan,
Thanks a ton for this!
I went through the new code in
webkit_debugger.dart— handling it with the 3-minute window andFuture.anyis super neat, definitely way better and cleaner than just bumping the timer.Tested it out on our project and it's working great now. Chrome connects right away on startup with zero timeout crashes.
Please go ahead with the cherry-pick to beta/stable whenever you can. It's going to save a lot of folks working on big web apps from this headache!
Really appreciate how fast you guys jumped on this and sorted it out. Thanks again!
nshahan commentedon Nov 6, 2026
@Markzipan
A new test failure on the windows config with this fix. dart-lang/sdk#64869