Change:
}); }); } else { <del> [terminal, error] = await this._createTerminal(task, resolver, workspaceFolder); </del> <ins> [terminal, error] = this._terminalForTask ? [this._terminalForTask, undefined] : await this._createTerminal(task, resolver, workspaceFolder); </ins> if (error) { return Promise.reject(new Error((<TaskError>error).message));

Discussion:
to start the default build ! This happened right after something strange, which might be the underlying cause. I had the build running already, the one with two terminals open. But I still pressed and noticed another two terminals showed up with the same build tasks! I closed them all. Then I pressed and ended up where the screenshot above shows. cc
I reloaded, then pressed before the workbench was done loading and got this: ! I waited a bit more, pressed it again and it worked. This is very likely a separate issue, so feel free to treat it as such.
might be a bug with the new reconnect?
Yeah I think I saw this once
That's exactly right. Steps: selfhost setup Shift B, you now have 2 build commands running VS Code VS Code, you still have 2 build commands running Shift B, You now have 4 build commands running.
C the old ones The new ones appear loading, even though they have finished compilation: ! Worse: the window horizontally, and eventually you'll get lucky and the spinning icons dissappear: !
it's not a new bug that you can launch tasks that are already running
If you press you should get the default build tasks, which are long running. If you press it again, they shouldn't be launched again and they aren't. This is good and expected. The bug is: restart Code (tasks now get restored), press and you'll get the same build tasks running again. This shouldn't happen: !
same root cause as , which is not new
This is my selfhost setup. I am 100% sure this is new.
the two bugs that you've identified here though are: the error about a terminal group command not found was already aware that statuses do not work after reload
in your old setup, run ctrl shift b, ctrl shift b again. you'll get 4
in stable !
I think you are correct it's a different issue. I see what's going on now.
might still be the same root cause, but i'll try to investigate for a bit
Thanks
could you pls verify this is fixed for you in insider's keeping in mind these two that I have a PR out to fix as well?
Sorry for reopening but I could still repro in today's build () very likely due to the . !

This is happening because this conditional is entered on ctrl+shift+b after reload: Looks like isn't restored on reconnect: !
The task has the wrong id? !
is persisted as a guid, not the expected string? !
It's the custom task with the same label that gets the uuid:
ends up returning true, that's why _id ends up as a uuid: The task's type is undefined after reconnection. It's mean to be , this is what it's meant to be: !
Note that this only reproduce for compound tasks.
That was a journey and I'm ready to throw in the towel for now. I believe the issue is either compound task state is not restored properly after reconnect here: And/or the recently used tasks cached value does not contain all recently used tasks as I only see the compound and Core - Build, no Ext - Build.
any thoughts would be appreciated. I spent ~ 3 hours on this and Daniel did as well.
I will take some time tomorrow to dig into it.
Some notes from debugging: When comparing tasks that come out of the recently used task list, they must be compared by their recently used key as this is the only stable id value (map key and task id can change). Instead of having a separate code path for reconnect, which is what is causing some state to be lost (like the ), if possible, it would be better to try the reconnect in the same place that we currently create a terminal. This would hook up all the needed state again and re-attach problem matchers. I've made an example PR here that starts to address the above points. Note that this is relatively untested, I just checked whether it fixes the problem described in this issue. Other notes: Using the recent tasks from the task service for re-connecting is problematic since users can use to entirely disable recent tasks. Instead, you will probably need a separate LRU that functions exactly like but is only used for reconnection. Tangentially related: you also need to nudge/rerun problem matchers on terminal lines that have already been written so that they can find their start pattern and the task doesn't have a spinner forever.