Dangers of mismatched transactions when the final editor state appears correct?

[prosed]

I’m wondering what the danger of mismatched transactions is when the editor state appears correct, history correct, decorations correct - everything seems to be correct.

We get this when we chain a selection-related command after the splitListItem command but I can’t find any harms that seem to come from this error no matter how vigorously I test it and try to break the editor after this mismatched transaction occurs.

Are all mismatched transactions inherently dangerous? Is there any harm to wrapping this command in a try/catch block and moving on with our work? The alternative would be to make a gnarly custom command, but that seems hard to justify since the current code seems to work.

[marijn]

@prosed

Are all mismatched transactions inherently dangerous? Is there any harm to wrapping this command in a try/catch block and moving on with our work?

Not if you don’t care about their effect not taking place.

But if code is causing this error, that code is probably doing something wrong (for example reading a state and then asynchronously using it to dispatch a transaction later), and it might be a good idea to fix it.

[prosed]

Thanks for your reply @marjin.

@marijn

Not if you don’t care about their effect not taking place.

But every effect seems to take place as intended; that’s my confusion here.

The end result is correct and each step in my chained commands relies on the one before it “properly” executing. It throws that error, but it still seems that every command has actually succeeded.