In my case, I had a custom error parser that would produce something that the linter would not like. This would cause an exception (duly reported), but then the busy signal stays on and I can't restart the build.
Looking at the code, I think I could find where the problem happens: the child process on('close') handler does a lot of thing before spawning a new promise that will finally remove the busy signal. Any error on this code path will lead to the busy signal not being reset.
I'm however way too green in javascript to know where is the best way to handle the error to make sure the busy signal is reset in all error paths...
In my case, I had a custom error parser that would produce something that the linter would not like. This would cause an exception (duly reported), but then the busy signal stays on and I can't restart the build.
Looking at the code, I think I could find where the problem happens: the child process on('close') handler does a lot of thing before spawning a new promise that will finally remove the busy signal. Any error on this code path will lead to the busy signal not being reset.
I'm however way too green in javascript to know where is the best way to handle the error to make sure the busy signal is reset in all error paths...