Stop starting new files after a panic with --halt #789

Today

With --halt, the engine rejects with a panic on the first error, but the files that are already in work, and the ones after them, are still changed.

The workers in engine() (src/engine.ts:160-167) each take the next file until there are none left. When one worker throws a panic, Promise.all rejects, but nothing stops the other workers. They go on taking files from next.

Run the engine with 40 files, voidAsync: false and halt: true, where the first file can not be read:

fs.chmodSync('00.txt', 0);
await engine({...config, includeGlob: ['*.txt'], voidAsync: false, halt: true, pattern: 'foo', replacement: 'bar'});

• The promise rejects with the panic. 0 files are changed at that moment.
• 500 ms later, all 39 other files have been changed.
• status.files.updated also grows after the panic.

Seen on main (6ea7b83) with Bun.

The CLI does not show this, because it ends the process right after the panic. But it breaks "the engine throws a panic when the run can not go on" from devguide.md, and it hits:

• Anyone who uses the engine as a library.
• rr() in test/helper.js, which puts the spies on stdout and stderr back while the workers still print.
• printDone(), which runs before the late prints, so --nl can be wrong.

Change

Stop the workers once a panic is thrown: a flag that the worker loop checks before it takes the next file.

Add an engine test with voidAsync: false and --halt that checks that no file after the error is changed.

Good to know

A file that is already being read or written when the panic comes will still finish. That is fine: the point of --halt is that no new file is started.

Reference

• Let the engine return a status report and the CLI own the process to close #742 #744 / Let the engine return a status report and the CLI own the process #742
• Limit how many files are handled at the same time to close #708 #740 / Limit how many files are handled at the same time #708 (the workers)