I think we are seeing a flow where an interrupt with errors occurs but a queue workflow transition still commits a workflow change. Asking to confirm if this is expected functionality?
The flow is a little messy but hopefully makes sense:
- LB A calls LB B with adopt all messages = false.
- Inside LB B I call a couple different calls but for this scenario:
- We first have a Called Logic block via a Call a Logic Block - Dynamic action, LB C (adopt all messages = true). LB C ends up queueing a workflow transition.
- Back in LB B, we have a second LB called. This one is LB D ( Adopt all messages = true), and inside LB D we hit an interrupt with error action.
- Back in LB A we take the messages from the message list, insert them into an error subtable and push a warning message back to the user.
As the transaction boundary closes we see the queue LB actions execute and commit the update to the database. The same functionality occurs with an insert action within LB C too.
cc @claire.minnaar so you can also keep track.
Yes, expected. The boss here is the outermost LB (A). Did A end with errors in its message list? No it did not, so A issues a commit. Since A committed, the workflow transition that was queued by C will also fire, as will any DB operations that were hit.
The semantic of that outermost saying “don’t adopt” could also be translated as “I get to decide about your commit”. And that counts for everything downstream that wasn’t in a separate transaction boundary. A separate transaction boundary might be what you intended the boundary of A calling B. Reading between the lines I think you wanted A to be responsible for changing how errors are reported. Nothing more. Starting with the call to B you wanted atomic behavior - either it all works or none of it works. Assuming I’m right you should make a new transaction boundary. You can still get the errors returned to A, but the presence of any errors is disconnected from the decision to commit.