I am running into this problem as well and any opinions would be very welcome.
The run into the reentry assertion check when performing undo with an undomanager that undoes changes to a large valuetree structure. This can easily happen if a valuetree propertychange leads to changing other properties. When undo is performed, the order the changes are undone is not necessarily well defined and therefore sometimes a triggered property change will trigger the reentry assert. Or it’s recorded as a new transaction right away which is also not desirable as it kills redo.
I am adding undo support to my large codebase and I didn’t consider this to be a problem until now. I understand that ideally all changes to the data model would come from the same source, but that’s not just not the case. Instead of rewriting a lot of code I’d like to have a method that tells me the undo manager is currently undoing changes. I know it will for sure undo the secondary changes to the correct values, but as said, maybe in the wrong order. What I now have done is add a flag so I can query whether undo is currently in progress, but why not have this in undomanager? Or maybe have the option to prevent undoable actions alltogether while undo is still in progress. If the state before the undo was valid, there should be no reason to add any new actions during undo (unless some stuff is missing from undo).
I understand this only happens if the code structure is not perfect, but I guess any larger project has areas where code is not as ideal as it could be and for those cases this would be very desirable.
How do others deal with this issue? How do you avoid valuetree changes that trigger other changes?