code --wait no longer exits when the file is closed in VSCode Insiders

[camillol]

Type: Bug

The symptoms are identical to #205416. That one was fixed in code-insiders, but in the latest version of code-insiders it's back again.

VS Code version: Code - Insiders 1.89.0-insider (Universal) (b58957e, 2024-05-01T02:05:29.995Z)
OS version: Darwin arm64 23.4.0
Modes:

System Info

Item	Value
CPUs	Apple M2 Max (12 x 24)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: enabled_on direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled webgpu: enabled
Load (avg)	14, 12, 10
Memory (System)	32.00GB (0.07GB free)
Process Argv	--crash-reporter-id 7b87a5b2-68e7-4d42-ad22-32e3bce2e5e7
Screen Reader	no
VM	0%

Extensions (22)

Extension	Author (truncated)	Version
ruff	cha	2024.20.0
gitlens	eam	14.9.1
copilot	Git	1.186.0
copilot-chat	Git	0.15.0
vscode-pull-request-github	Git	0.86.1
go	gol	0.41.4
vscode-cython	ktn	1.0.3
marp-vscode	mar	2.8.0
python-path	mge	0.0.14
black-formatter	ms-	2024.2.0
debugpy	ms-	2024.5.11172029
isort	ms-	2023.13.10681007
python	ms-	2024.4.1
vscode-pylance	ms-	2024.4.1
jupyter	ms-	2024.4.0
jupyter-keymap	ms-	1.1.2
jupyter-renderers	ms-	1.0.17
vscode-jupyter-cell-tags	ms-	0.1.9
vscode-jupyter-slideshow	ms-	0.1.6
makefile-tools	ms-	0.9.10
sourcegraph	sou	2.2.16
even-better-toml	tam	0.19.2

A/B Experiments

vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstes627:30244334
vscod805:30301674
vsaa593cf:30376535
py29gd2263:31024238
c4g48928:30535728
vscrpc:30624061
962ge761:30841072
pythongtdpath:30726887
welcomedialog:30812478
pythonidxpt:30768918
pythonnoceb:30776497
asynctok:30898717
dsvsc013:30777762
dsvsc014:30777825
dsvsc015:30821418
pythontestfixt:30866404
pythonregdiag2:30926734
pyreplss1:30879911
pythonmypyd1:30859725
pythoncet0:30859736
2e7ec940:31000449
pythontbext0:30879054
accentitlementst:30870582
dsvsc016:30879898
dsvsc017:30880771
dsvsc018:30880772
cppperfnew:30980852
ccp2r3:30958153
pythonait:30973460
showvideot:31016890
chatpanelt:31014475
9c06g630:31013171
pythoncenvptcf:31022791
a69g1124:31018687
88717513:31021561
dvdeprecationcf:31036533
pythonprt:31036556
dwnewjupytercf:31035177

[bpasero]

I cannot reproduce:

Please provide more info for me to reproduce this.

[vscodenpa]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[antcodd]

I am seeing the same issue since upgrading to the latest stable 1.89.1 on Linux.

To reproduce: It appears to only occur when Open Files in New Window is off and a window is reused.

This breaks many built in git workflows like Commit (Amend) and popular git extensions like Gitlens rebase, even when the git editor is not explicitly set to code --wait. The operations never complete when closing the editor and git features become unusable until restarting Code. I have also been seeing hangs when switching branches sometimes which may or may not be related.

Please reopen this issue and consider it for a recovery build if there is another scheduled. I've been forced to do manual rebasing in an external terminal with another editor the last few days and frequently restart Code from hanging git workflows.

[bpasero]

What are your exact settings to reproduce this, what window(s) are open and how do you trigger --wait?

[bpasero]

Even with window reuse I cannot reproduce, here I open a file into an existing window and the process in the terminal exits when I close the editor:

[antcodd]

I am using this combination of settings:

window.openFilesInNewWindow: off
window.openFoldersInNewWindow: on
window.restoreWindows: one
files.hotExit: onExitAndWindowClose

Intersingly I just tried toggling window.openFoldersInNewWindow: off (the default) and the problem went away. Then I toggled it back to on and it didn't come back. Will try relaunching Code shortly to see if it comes back.

I could reproduce just by using literally code --wait foo with a folder with git open in Code. I also have several unsaved temporary windows open that restore automatically.
I have also seen it with trying to use Commit (Amend) and the commit message editor not being detected as closed.

[bpasero]

Please ping when you have a consistent repro, it seems undeterministic.

[antcodd]

And now I'm having trouble reproducing it again, it was reproducing reliably before. I had restarted Code and the machine several times over the last few days to try to work around the issue.

[camillol]

This is still happening all the time to me, on Mac, with no special window settings that I recall.

I do have a few workspace windows open.

[bpasero]

👍

[camillol]

I noticed that when I run code-insiders -w file, a new icon pops up in the dock. The file shows up in a tab in my current workspace, though. And closing the new, windowless instance of the app does not terminate the wait, nor does closing the tab with the file. It only stops waiting when I quit the original instance of the app (with all the windows).

[bpasero]

Yes, that is expected behaviour, do not close that second dock or expect that to return the process. Ideally we could avoid showing a second dock entry, but we failed at it, you can ignore it.

[camillol]

Ah, I see.

If I look at developer tools, the console shows a bunch of errors from File Watcher ("too many files open"), and several "REFUSES to accept new listeners because it exceeded its threshold by far".

Actually, whenever I do a code-insiders -w, I get these:

The first three appear when the file is opened, the fourth when it's closed.

[bpasero]

I am not sure that is related.

[antcodd]

I managed to reproduce the problem slightly more reliably.
Toggling window.openFilesInNewWindow: On with the settings editor:
code --wait foo
Close window without saving. Wait exits properly.
Toggling window.openFilesInNewWindow: Off with the settings editor
code --wait foo
Close tab without saving. Wait hangs.

Sometimes changing another setting unsticks Off, then it works for a while.

I am also seeing the REFUSES to accept new listeners because it exceed its threshold by far.
This appears to be resource leak handling code. Maybe the file close event isn't getting through due to this?

I also have quite a few open files, Code is showing around 300 open file handles for some processes (ulimit is 1024).

[antcodd]

I think it is something to do with the number/set of open editors in an editor group.

If I focus the top editor group in my workspace I reliably get the issue.
If I focus the bottom editor group which has fewer tabs I reliably don't get the issue.

I think that also lines up with my previous experiments (focusing other groups without noticing)

[bpasero]

I can also not reproduce when I have 2 groups open, even when the file in question is already opened.

[camillol]

I can confirm that if the file opens in a window with fewer tabs (I reproduced this by focusing a different workspace window and opening a file that's not in any workspace, so it just opens in the frontmost one), then code-insiders -w terminates correctly when the file is closed. And I don't see the logs from #211866 (comment).

If you want to reproduce this, you need to open a bunch of files.

[antcodd]

It turns out I have several hundred tabs open in the first editor group (not sure of the exact count, I though it was visible in one of the quick pick lists but can't find it).

I tried opening ~550 new files in the other group and that didn't introduce the problem, but I guess those are lighter weight than source files. Also tried diff editors and files open in other locations and that didn't change anything either (there aren't very many of those).

It's possible we're hitting some kind of reasonable limit somewhere. I don't see the problem with projects with more sane numbers of tabs.

[bpasero]

So to clarify: you see the issue when you have e.g. 200 tabs open, but not with less?

Its true that we have some listener leak protection in place, but that is only number based and having 200 tabs open is not necessarily a leak, but could hit that hardcoded limit, I will check.

[bpasero]

Even with 200 untitled files open (which is easy to do quickly via Cmd+N) I cannot reproduce, though I do see the leak warning. The warning itself will not prevent the listener to work though, we have another limit for that: 3*175, are you possibly having more than 500 files opened?

If so, you would see a message like this one in the devtools console: REFUSES to accept new listeners because it exceeded its threshold by far

Can you check?

[antcodd]

In my case I think that is what happened. That is the same message as the screenshot above. When I was counting it was around 520 tabs. I couldn't reproduce with untitled files but perhaps they need to be saved or have some content.

I'll try cleaning up that editor group tomorrow, in batches and see if that resolves the issue.

The solution might be to not open that many tabs... They tend to disappear off the scroll bar never to be noticed again as I mostly use Ctrl-P except for a few recent tabs. I should probably make use of the recently introduced option to limit the number of open tabs.

[bpasero]

Thanks for being patient with me, I was able to reproduce the issue when you have more than 500 tabs open. We have a way to increase the limit for event listeners to support this scenario. I know made the threshold be 500 which means features will stop working if you have 1500 editors open, which is probably more than enough.

Anyway, this is not a full solution for all features in VS Code. I can only say that it is not recommended to have so many tabs open if you can avoid it, certain features may break.

[antcodd]

Thanks, I was a bit shocked that many tabs were open but it probably explains some of the transient quirks I have seen occasionally. Thanks for looking in to this so promptly and interactively. Now that we understand the cause I feel a bit silly sounding urgent, I can just clean up some tabs for now. I'll also try out some of the features that help with tab management like autoclosing and per-branch state.

If it isn't already it might make sense for the resource usage warning at 1/3 the limit propagated to the GUI like the too many git files warning. With the increase its unlikely I'll hit it again though.