@isidorn In general this is an issue with the reference-ID-generation in the debug adapter.
However this time it looks like there is a bigger problem.

I can reproduce this with the node-debugger.
Use this code:

let a = [];

for(i = 0; i < 100; i++) {
	a[i] = i;
}

• Set a breakpoint on the statement inside the for-loop.
• start debugging
• expand array
• press "continue"

Observe:
array stays expanded (as expected).

• press "step"

Observe:
array collapses.

@weinand the issue here is that the stack frame of the frame changes. Before pressing "step" the stackFrame has the id 1000 and after pressing "step" the stackFrame has the id 1001.
For the vscode ui these two frames are then considered different.

In order to fix this the debug adapter should return consistent frameId for same frames across steps.
As an alternative vscode could use the name of the stack frame when generating the id. Though using the current approach seems better to me.

Assigning to @weinand and @roblourens to see if the stackFrame id can be preserved and removing the milestone.

@isidorn the original problem occurred in the Java debugger. Fixing this in node.js debugging doesn't help that much for Java.
Please explain the Java folks what to do.

Dear Java folks,

VSCode is using the tree to represent the variables in the variables view. In order for us to keep the expansion state we need to uniquely identify each element in the tree.
For that we compute a unique ID for each element: Scope, Variable and so on.
Currently for the scope ID computation we use the StackFrame.id
In case you are interested here is where we compute the ids pointer
We use that to be consistent since each element takes into account its parents id.

In practice we could remove this. And that each scope does not take the parents ID into consideration. We can only do this because in vscode ui we never show multiple scopes from multiple stack frames at the same time in the tree. Our variables view is always scoped per StackFrame.

So we have two options to fix this.

1. Java makes sure that the StackFrame id does not change when it does not need to
2. VSCode no longer takes into account the stackFrame id when computing the scope id - this is a change which I could only push in debt week and only after self hosting on it for a milestone I would be comfortable with shipping this

Bottom line: I like the current id computation which is dependent on the parent and I would prefer to got with 1). If that is not possible than I can look into 2)

ping @testforstephen

i have two questions here:

1. In my environment (VS Code 1.34.0), sometimes the expandable status is kept after step, sometimes it collapses all indexable variables. The behavior is not consistent, looks like a bug.
2. For java debug, the JVM debug interface didn't provide us much information about the stack frame is changed or not during the step. We can only guess whether the stack frames are changed by comparing the total stack frame count with the last count. If the stack frame count doesn't change after step, it may indicate we can reuse the same frame id for the stack frame with the same depth. But this approach looks like a hack. I prefer the vscode client to deal with it.

1. This is 99% becuase the id coming from the adapter changed. As I have mentioned in my previous comment, for each item in the variables view we compute an ID, this ID is based on the ID of its parent chain, and for each element we compute the ID using data coming from the debug adapter. If an element like for example StackFrame has an ID then we will use that to compute our own ID. Thus if that changes, our ID changes and the expansions status is not kept
2. Ok, let's try that I no longer take into account StackFrame.id for the scope. I will push this next week and you can try it out and let me know how it goes.

I have pushed these changes. The insiders in about a week should have these chagnes
@tommai78101 @testforstephen let me know how it behaves for you know. Looking at the sample @weinand provided this is fixed now. Adding bug label so we verify this.

@isidorn I may not likely be available to test this change, since I am preparing for a long, family vacation trip coming up really soon. I won't be available to test this until July 2019. Just letting everyone know in advance.

I tried in the 1.36.0-insider with 2019-06-07T05:19:15.188Z version, the expanding status is kept after step. It works.

Great, adding verified label. Thanks for trying it out.