I'd like to understand this change better, but I'm not familiar with much of this code - could you expand on what the updateRegisters are used for?

is there a way to transform the force update of input nodes into a mock modification? What are the big differences between a force update and a modification?

I'd like to understand this change better, but I'm not familiar with much of this code - could you expand on what the updateRegisters are used for?

@mjkkirschner the updateRegisters dictionary is a dynamic data structure to hold the values of input nodes that are modified in delta execution. They are not real registers but represent the concept of a VM register that stores a stackvalue. The following is an example of the instructions generated for an input node:

e.g. [a = 1] where a represents an input
---------------------------------------------
push 1
pop lx	(register)
-------------	⇒ No graphnode
push lx
pop a
dep a               ⇒ graphnode
---------------------------------------------
=> [a = 2] (delta update to the input)
---------------------------------------------
update register to 2 directly instead of emitting new instructions to push the value of 2 to lx and update it that way

Since we can have multiple input nodes at a time, I cannot use a single register (called lx in this example), so I decided to use a dictionary with key = AST ID of the node, value = stackvalue. Now, whenever an input node with a unique AST ID, executes, its stackvalue is either added to the dictionary or updated in the dictionary if it's an update.

is there a way to transform the force update of input nodes into a mock modification? What are the big differences between a force update and a modification?

In a delta modification, the modified subtrees/ASTs are identified by the change set computer. Among those modified ASTs, I was identifying the input nodes, and directly updating the update-registers to the RHS of the modified AST. This is because, in #12835, I assumed that the RHS of input nodes will only be primitives, so I can do this update by directly looking at the AST and getting the value, then updating the register.
Then this FormIt case came along where the input node is a FormIt selection node (NodeModel node) and is internally a call to Geometry.ImportSAT(filename). Therefore, the RHS of its AST is not a primitive but a return value from a function call, which is only known at runtime. In this case, when the selection was being changed, it wasn't being identified as a modified AST by the change set computer because the SAT file name is unchanged by FormIt's selection node. FormIt simply swaps out the geometry from underneath keeping the same file name. However, the node was still executing since it was marked for force-execute. In neither the "force-re-execute" cycle, nor the modification cycle, can I check for the graphnode's updated value unless it's actually computed in the VM and returned, and only then can I update the input register. Therefore I'm marking this graphnode ahead of time, then tracking its execution, and finally updating the register in the pop instruction when its value is popped. Then in the subsequent push instruction when the register is pushed for assigning to downstream symbols, I can ensure that the register has the updated value. To fix this, I no longer skip executing the instructions to push the updated value and pop it to the register. These are skipped only for primitive values.

In this case, when the selection was being changed, it wasn't being identified as a modified AST by the change set computer because the SAT file name is unchanged by FormIt's selection node.

Is there a way to mark all nodes that are force re-executed as changed in the change set computer?

In this case, when the selection was being changed, it wasn't being identified as a modified AST by the change set computer because the SAT file name is unchanged by FormIt's selection node.

Is there a way to mark all nodes that are force re-executed as changed in the change set computer?

I don't think it really matters in this case. Even if we consider these force-reexecuted nodes as modified nodes, we'll still have to track the graphnode identified at this stage all the way up to the pop instruction where we can get the stackvalue returned and update the register. This is why I had a TODO in the PR description to do the same thing I'm doing for force-reexecute for modified nodes.

@aparajit-pratap awesome! Is there a way to test this?