Change:
Issue Type: <bBug</bSee the , which provides two tasks and and a README with these steps. the task the task again. that each failed in its own terminal, despite what the message in the terminal said. the terminal and press a key to close it. the task . the task again. that both failed in the same terminal, again not shared with the task. closing the terminal, run the task again. that the task reuses the terminal now, but doesn't fail. Instead it just produces no output at all, and doesn't seem to signal that it's finished. The task doesn't hang, it just fails. Its terminal gets reused like the one from . Ideally both tasks would emit the exact same sequence events, including both and so the listener can determine that the task failed. VS Code version: Code - Insiders 1.63.0-insider (, 2021-11-29T08:08:44.056Z) OS version: Linux x64 5.15.4-201.fc35.x8664 Restricted Mode: No <details<summarySystem Info</summary </detailsExtensions disabled<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
or I think the cause of the problem is that doesn't fire when a process task exits with an error like this. I don't think there's anything suspicious in the shell launch configs: ! Would you expect to fire if the process errors out early like this (the command to run doesn't exist)?
When the call to create/start the process fails, like when doesn't exist, it should fire the event here:
It does do that, but it seems that something is still not cleaned up somewhere as process tasks run in a re-used terminal don't output the message at all.
If you have this repro set up could you also log these? This is where the output happens:
In a non-reused terminal: is set to undefined there. is set to the expected message. gets run and gets hit. In a re-used terminal: None of those lines are hit. When I kill the terminal manually they are all hit, but all those values are undefined.
This looks much better than before! However, I still see the task's terminal have an . Is this expected? Tasks expects the exit code to not be in this case because it indicates that the terminal is being disposed and cannot be reused: Because of this, tasks doesn't keep the terminal around in the task system for re-using, so subsequent tasks will get a new terminal, which is unexpected.
I think undefined for is expected here because a process never launches, instead it fails because the executable is missing before we try to launch the process. This is different to which would run something like and that would exit.
is there a way I can tell on the tasks side if a terminal is being disposed vs. just had the above situation happen? I'd like to reuse it if it's not being disposed so that the user experience is consistent. Just iterate though the and see if the instance with the same ID is still there?
Internally we use to differentiate these: I guess we could just expose that as a type in too, looks like tasks is still the only consumer that uses the value on the event I believe. If you want to try this, change this line: To this or similar:
I'll make the tasks changes in February:

Discussion:
// Set the new shell launch config this._shellLaunchConfig = shell; // Must be done before calling _createProcess() <del> this._processManager.relaunch(this._shellLaunchConfig, this._cols || Constants.DefaultCols, this._rows || Constants.DefaultRows, this._accessibilityService.isScreenReaderOptimized(), reset); </del> <ins> await this._processManager.relaunch(this._shellLaunchConfig, this._cols || Constants.DefaultCols, this._rows || Constants.DefaultRows, this._accessibilityService.isScreenReaderOptimized(), reset).then(error => { if (error) { this._onProcessExit(error); } }); </ins> this._xtermTypeAheadAddon?.reset(); }