Repository navigation
First test run in a session triggers slow discovery of all test suites #5879
Description
Describe the bug
After running a test file with test_reflective_loader, I see all gutter icons just fine, but if I right-click to debug a specific test, I see the Discovering Tests... status for a very long time.
Simply restarting the extension host reproduces it. I don't need to edit anything to see this behaviour (tested on the SDK just now).
To Reproduce
Steps to reproduce the behavior:
- Open a
test_reflective_loadertest file - Run it fully
- Try using the gutter icon to debug a single test
Expected behavior
For it to immediately start the debugger (not needing to discover tests).
Extra
I'll see if I can profile the extension to send some more info here.
Please complete the following information:
Workspace Environment
Dart Code extension: 3.127.20260115
Flutter extension: 3.127.20251229 (activated)
App: Visual Studio Code
App Host: desktop
Version: win 1.108.1
Workspace type: Dart (LSP)
Workspace name: essential_lints
Dart (3.12.0-edge.2bfdb03c4afd1592ca3c35bfa8e87c19a9db0c95): C:\Users\felip_0vh5fa6\dart
Flutter (3.38.6): C:\Users\felip_0vh5fa6\.puro\envs\stable\flutter (No device)
Output from 'dart info'
C:\Users\felip_0vh5fa6\dart\bin\dart.exe info
If providing this information as part of reporting a bug, please review the information
below to ensure it only contains things you're comfortable posting publicly.
General info
- Dart 3.12.0-edge.2bfdb03c4afd1592ca3c35bfa8e87c19a9db0c95 (main) (Sat Jan 17 17:33:05 2026 -0800) on "windows_x64"
- on windows / "Windows 11 Pro" 10.0 (Build 26200)
- locale is pt-BR
Project info
- sdk constraint: '^3.10.0'
- dependencies: analysis_server_plugin, analyzer, essential_lints_annotations, logging, meta
- dev_dependencies: analyzer_testing, frontend_server_client, test, test_reflective_loader, very_good_analysis
Process info
| Memory | CPU | Elapsed time | Command line |
|---|---|---|---|
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dartvm.exe | |
| 0 MB | -- | dartvm.exe |
Activity
DanTup commentedon Jan 19, 2026
I don't see "Discovering tests..." in my status bar for some reason, but I do see a long spinner on the test node in the Test Explorer.
It seems to be caused by a bit of a hack we have here... When we're asked to discover test for a file, we need the Outline data. We attempt to get it by forcing a request for a Hover for that file. However shortly after startup when the server is busy, this hover can take a long time:
So we end up waiting for this whole period, and then wait up to 5s more for the outline.
So at a minimum, we probably shouldn't wait for the hover to complete, but ideally we would not require this hack at all, and have a way to discover tests (get the outline?) for a file specifically. documentSymbols might be a reasonable request for this data, but it might not include the Test metadata that Outline has.
DanTup commentedon Jan 19, 2026
Actually, switching to document symbols here wouldn't solve my problem - because if the server is still starting up we wouldn't get the response to that yet either. If discover is triggered while the server is busy, I think we've no option but to wait.
However, I'm less sure now that this is the same problem that @FMorschel is seeing... Can you confirm whether you only see this issue while server is starting up, or if you wait for initial analysis to complete completely, do you still see a very slow "Discovering" when running the test?
(note: we can't control when VS Code asks us to discover tests, nor do I think we should try to guess if the results we have are the full set of tests unless we can do it reliably)
FMorschel commentedon Jan 19, 2026
Yes, I can confirm the server had already finished the initial analysis. I had refactors/quick-fixes/assists showing already, as well as hover docs. Once all of that was responsive, I ran the full test file. Once it was completed, I right-clicked a failing test on the gutter icon and asked to debug it. I see the
Discovering Tests...status.FMorschel commentedon Jan 19, 2026
Here is the extension profiling you asked for on Discord for this issue:
CPU-20260119T154129.440Z.cpuprofile.txt
DanTup commentedon Jan 21, 2026
I was just testing this again, and while I thought this had completed, it actually had not. I think this might be related to slow plugin initialization, and the server being "blocked" on it.
If I wait until the I see the 11 warnings show up for the example project and then invoke it, test discovery is instant.
So there might not be much to do here - I think it's better to keep waiting for the outline data to discover tests than to just bail out early. The fact that it's blocked behind plugins is an issue that I hope can be fixed, but isn't something to do here.
@FMorschel does this make sense? Can you confirm that the delay you see is only until the warnings appear, and that it is just being blocked by the plugin?
DanTup commentedon Jan 21, 2026
Sorry, I didn't address this point properly.
It is by design that we run test discovery even if you've run the file. Discovering tests here is the static discovery that finds normal tests. We can't trust that a set of results included all tests in a file, and we prefer to track tests from their static definitions in the outline data (since they are always up-to-date, whereas results might be stale).
However generally it should be very fast and so my focus here is on why it's not fast, not trying to avoid it.
FMorschel commentedon Jan 21, 2026
I just did:
pkg/analysis_server/test/src/services/completion/dart/completion_test.dartF5once completions, reactors, hovers and everything else are responsiveConvertedTestCases.test_001_1and selectDebug TestHere are the
Capture Analysis Server Logsfor 3 and 4:Dart-Code-Log-2026-00-03 12-38-46.txt
[-]`test_reflective_loader` tests need discovering even after running file[/-][+]First test run in a session triggers slow discovery of all test suites[/+]Don't perform test-suite-discovery when running specific tests
Don't perform test-suite-discovery when running specific tests