Wallaby stalls on file save in VSCode

[mouettxy]

Issue description or question

Basically title. I tried looking at diagnostics, my first impression was that I tracked too much files. After reducing tracked files with wallaby to absolute minimum, issue still persists.

The flow that I have is following:

• Execute Wallaby.js: Start
• Wait for it to run
• Save file - it runs ok
• Save file another time - it stalls, usually on "Queueing tests from N files"

Can you please guide me where I should look next to troubleshoot this error? It's basically stops me from using Wallaby reliably

Wallaby diagnostics report

diag.txt

[smcenlly]

Thanks for the diagnostics report, we believe we have found and fixed the issue you were having. Could you please update to the latest version of Wallaby core, v1.0.1892 and let us know if you're still having problems?

[mouettxy]

Thanks for the diagnostics report, we believe we have found and fixed the issue you were having. Could you please update to the latest version of Wallaby core, v1.0.1892 and let us know if you're still having problems?

Updated to v1.0.1893 and still seeing the same issue with stall. Logs now spamming something along the lines of: Still running: 17 test file(s) in 5 worker(s)

diag.txt

[smcenlly]

Thank you so much for providing the updated diagnostics report.

Could you please update to Wallaby core v1.0.1894? We've made further changes that we believe will address your issue. We have a few more updates for further improvement also planned for next week (related to the root cause - a bug in our vitest health check).

[mouettxy]

Sorry, I will temporarly need to do a lot of work with my tests, so I heavily rely on Wallaby.js. I downloaded new version, and it's still stalls, but I reverted back to older version without doing diag report, sadly

I temporarly downgraded to v2, and planning to wait some time before v3 goes stable

Very appreciate if you communicate some status from QA more public, seems like this is not first issue. Also, when I checked out new update - time for cold start was pretty much faster! Very aprecciate your hard work and good luck with nailing update

[smcenlly]

Thanks for the update. We just wanted to let you know that we've been working on a fix for your issue and should have more to share in the next day or so.

[smcenlly]

A bit of background: Wallaby's v3 release shipped with some large-scale changes to our Vitest integration. These changes shift responsibility for determining test execution order from Vitest to Wallaby and provide a more responsive test execution experience. Unfortunately, while all our existing integration tests passed, there were some combinations of settings and scenarios that led to races or clean-up failures that impacted some workflows, yours included.

Since our last update over the weekend, our team has been reviewing and retesting our Vitest integration. We identified a number of problems that may have affected you and addressed those issues:

• FIXED – The AbortSignal for the worker run was being re-created for each test file in a worker; now the same abort signal is reused until the worker completes or is cancelled. This could cause race conditions, hung executions, or attempts to continue running with an invalid test context.
• FIXED – Wallaby v3 Vitest integration was missing an internal worker message sequence number used to avoid out-of-sequence IPC messaging. This could result in a ~100 ms delay in message processing and a loss of stack trace information when processing error messages.
• FIXED – Issue when using pool: 'threads' and isolate: false where subsequent tests in a worker would fail to load.
• FIXED – Issue when cancelling and rescheduling an in-progress worker where the cancelled test run context would be overridden with the new context. This could lead to inconsistent or incorrect results being executed for the cancelled test run.
• IMPROVED/FIXED – How Vitest workers are terminated. Previously, execution could hang, preventing further work from being scheduled.
• IMPROVED – Worker process health check previously relied on a specific “healthy” message but now uses any received IPC message as proof of process health. This improves latency and processing times.

---

We’d appreciate it if you could try v3 again to confirm that the issues we’ve addressed have fixed your problem. We’ve also made some updates to Wallaby for VS Code to make this easier for you to test.

The Wallaby VS Code extension (1.0.473) has a new command, Wallaby.js: Install Specific Core Version. This command can be used to install (and use) a specific version of Wallaby core. After using it, Wallaby will not automatically update unless you use this command again, or use Wallaby.js: Force Core Update. Please note: this command requires wallaby.noAutomaticInstall to be set to false or removed.

To test the latest version:

1. In your VS Code settings, remove the wallaby.noAutomaticInstall setting (you would have added this as part of our offline installation instructions to use a previous version of Wallaby).
2. Run the Wallaby.js: Force Core Update command to update to the latest version.
3. Confirm that your project runs as expected.

If the latest version does not work:
If the latest version doesn’t work for you, you can revert to the v2 version after testing the latest version:

1. Run the Wallaby.js: Install Specific Core Version command.
2. When prompted which version to install, select the version before v3 (or any version you prefer):

We hope the new Wallaby.js: Install Specific Core Version command makes it simple and painless for you to test the latest version or revert if needed. Once your issues are fully resolved, you should be able to stay on the latest version of Wallaby again for all future fixes, updates, and improvements without concern.

[mouettxy]

Wallaby.js: Install Specific Core Version - is a godsent, thank you!

I'll test new version and it seems much more stable now!

But now there's sometimes happen another issue. I think when I write new code that adds some new imports, or does not compile, Wallaby breaks and can't run tests after that

Diagnostics:

diag.txt

Sorry for big file, I will try to provide much more cleaner example if I had chance, but issue happens randomly

[ArtemGovorov]

@mouettxy Thanks for providing the diagnostics report! It helped us identify an issue that we’ve tracked down and fixed. Please update to the latest core v1.0.1912. If the problem appears again in the new version, please capture and send a new diagnostics report. No need to create a cleaner example, as long as the report is taken right after (or close to) when the issue occurs, it should give us enough information to investigate.