Change:
nodesToForget.set(child.element as T, child); if (this.identityProvider) { <del> const collapsed = this.tree.isCollapsed(child); childrenTreeNodesById.set(child.id!, { node: child, collapsed }); </del> <ins> childrenTreeNodesById.set(child.id!, { node: child, collapsed: this.tree.hasElement(child) && this.tree.isCollapsed(child) }); </ins> } }

Discussion:
Issue Type: <bBug</bAs of 1.64, built-in debug console in VSCode freezes after a short while and becomes completely unusable. I had filed an issue a while back () when the problem appeared, but it mysteriously went away after some changes were made to the project. I self-closed the issue as it went away, stating I'd file a new issue if it came back, so here we are. Long story short: when using (or just not specifying it), the debug console cannot switch between processes, does not take input from the console, and does not put out any messages from whatever process happens to be selected. Interestingly, however, collapsable messages (i.e. those with the click-able caret that shows more info) still work, but always display nothing. The problems dissappear when using , but many features are then lost. The Output is flooded with the following error: <details<summaryStack Trace</summary</detailsAs requested in the other issue, here's a short clip of the console being frozen: ]() Observe the left sidebar still correctly switching (as one is and one is ). The output that is visible here is actually old from a previous debugging session, and not even all of it: it appears to have stopped abruptly when trying to log an action. Clearing the console doesn't work either. For reference, here's the I've got for those two processes: <details</summary</detailsHappy to provide any other details as needed. Edit: Fixed the image VS Code version: Code 1.65.2 (, 2022-03-10T14:33:55.248Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I assume you are using 1.65 now, that's the version number in the details of your post do you understand what happened in that stack? I assume the debug console did something wrong, but at this line it seems like the tree is checking the collapse state of a child that might not have been to the tree yet?
Or that might've been removed since. Repro steps would be great here!
Sorry for the late response.

This was indeed in 1.65, but it started in 1.64, mysteriously stopped happening (not at the same time as an update), then started again after updating. My repro steps are quite literally "start the debugger, problem appears", so it must be something environmental that VSCode doesn't like. The project it keeps happening to is unfortunately a private internal project (and not a small one either) or I'd just share it, so I'm trying to isolate what it is that keeps triggering this. The project uses (and the default console logger with the simple format) to log on the node processes and the browser process only writes to console via . However 's output is rather complex sometimes, and that is where VSCode starts drawing many nested tree nodes: perhaps that? Edit: I had the idea to disable and test the project: the debugger output works fine. Something to do with the big objects it spits out, I think. The last thing I see in the debug console is one of three actions (that print at once), seemingly randomly, failing to finish being printed. <details<summaryScreenshot</summaryNote the oddidites with text color rendering (ignoring the color theme), and the middle of the three actions lacking its node. ! </details
The best way for us to help you is to get exactly the same environment as you. So, if your code is open-source just tell us where it is and we'll try to reproduce. The best steps you can provide to us are: Clone this, checkout that, start VS Code and F5.
The project is unfortunately not open-source (a large internal private project), but I will try to see if I can get a minimal repro I can share working.
Have the same issue here, always with the redux-logger output activated and the TreeError errors in the devtools console. After a couple of medium/small size state logs the debug console become unresponsive until i restart Code (1.67.0-insider). Sadly can't share the project `cause is not open nor mine.
apparently configuring the logger to collapse everything make the thing work,
same here, also more generally and are both broken in the integrated debug console (weird behaviour, auto-closing on their own uppon new logs, etc.)

That would be a different issue would be helpful if you open a new issue with repro steps I assume this is a tree bug, if you think this is due to the debug console misusing the tree API, you can assign back to me
Could you repro locally?
No
I understand that the code being closed source makes it hard to showcase the bug... but maybe you could come up with a sample that we could take and reproduce the issue on our side?
Myself and a few others have been trying on and off to get a minimal repro we can share, but try as we might the debugger appears to perform normally outside of our project, which is unfortunate in this case. It seems what we assume to be the problem is not actually the case, so I'm not sure where to go from there. On the plus side, fnicastri's work-around did help, leading me to think it's about tree depth, but even some trees I tested that were well beyond anything practical worked fine.
Thanks moving this to Backlog.
I, too, have been vexed over time with this issue. I just removed all traces of [x], and then I successfully got past this frozen debug console issue (which tonight happened as the app started). BTW, I should note that when the debug console froze, it was always when was open. The output never got to console.groupEnd(). Now, hopefully, I will be back to a normal excellent vscode debug experience (albeit with a noisy console <g/). At this writing, after removing et al., the debug console works fine. I sure hope this "fix" is one. If this is enough field intel for you guys to repro and fix, then maybe we can go back to using groups which are very handy when I have gobs of debug spew. Also, this week I made a collapseLog js helper function so that I could selectively use to show specific debug output (console.groupCollapsed is the default so I can have a mostly minified debug session. One last thing: try using this function in a sample app (I'm using and node). function collapsedLog({ heading, arg, open = false }) { const f = open ?

: console.groupCollapsed; f(heading); if (Array.isArray(arg)) { (arg); } else { (); } console.groupEnd(); } It may be that the indirection step that selects the specified function is confusing the debugger. And for the record, here's my vscode intel: Version: 1.69.0 (user setup) Commit: Date: 2022-07-07T05:28:36.503Z Electron: 18.3.5 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Windows_NT x64 10.0. read well and prosper... ^m
Yep, I just confirmed that collapsedLog() was the culprit. Here's the other helper function I use all over the place to handle callbacks consistently: This is where the console freezes every time: The collapsedLog() function never gets to the () or the () lines (maybe one or both of those two lines (probably the ()) is mucking things up. Anyway, I hope this stuff helps you guys keep doing a yeoman's job keeping us grunts out here productive...<g/rwap ^m
Ah, I am finally able to repro, using this code: Not every time. It sometimes fails and sometimes the tree updates just get slower and slower. The seems to help it repro.
Here's a stack with sourcemapped paths: If I start debugging the code above, this fails pretty much every time. Sometimes I have to wait 30s, sometimes it's quick. Debugged for awhile and I'm not sure what I'm seeing. I can keep debugging if you can give me some guidance. Maybe it has something to do with refreshing the tree at the same time as auto-expanding a group here: This scenario is append-only, there is no deleting At the point where it fails We called The tree is calling for every row It gets to this expanded group header, and calls setChildren with that and its one child At this line, checking whether the existing children for that node are collapsed The child does not exist in the tree, and the exception is thrown Here's what I see at the point where the exception is thrown <img width="835" alt="image" src="https://user-"The node in the model does not have the child, the element does.

I'm not really sure how we get into this situation. I keep trying to add logging to understand what happened, but that slows it down enough that it stops reproing.
I've tried over and over again and this still doesn't repro for me with that sample. Maybe we pair debug this?
ahhhhhhh - I'm not seeing it repro right now either. But it does get slower and slower to where it almost stops updating entirely. I can take another pass on looking at this next week.
I run into this quite often actually and it is very annoying.
A consistent repro case would be helpful
I cannot reproduce this, with the or in OSS debugging. My initial idea is that it could be an issue with non-unique or unstable IDs for tree elements, but all elements in the debug REPL use either UUID or are assigned by counters. The most smelly thing I found was the possibility of work happening between and , at which point the could have nodes that aren't yet in the tree. Specifically, any two calls to for the same node not separated by a call would lead to this error. In my unit tests, the concurrency guards in keep things in order, but their usage is pretty complex and not something I can confidently say I validated fully. Regardless of the soundness of the locking inside , the call to outside the async 'lock' does allow work to happen between the calls, if two microtasks are unlucky enough to be scheduled in such a way. Seeing how rare this issue is, at least for most people, makes the possibility of such sneaky races possible in my mind. The easy fix would be to simply check whether before checking the collapsed state. As I haven't been very successful in getting a repro, this is attractive to me as a certain fix.
- are you able to verify this since it sounds like you can hit it regularly?
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Yes, I didn't see it since then anymore.