Reversion Request: This action is not allowed as it is outside the current transaction.
After upgrading from Pega 6.2SP2 to Pega 7.2.1, previously working flow action processes are now showing, sometimes randomly, transaction id mismatch errors when submitting.
One example of a button with multiple steps is attached; these have been typically resolved by code updates. PegaSupport shows multiple similar defects, which are typically due to custom scripts / code, especially when occurring after the Finish Assignment task.
This request is to determine a possible hotfix that can revert the Submit / Finish Assignment behaviour to reproduce the working Pega 6.2SP2 functionality, so that Development does not need to review and update each of the multiple application error scenarios independently.
For reference:
***Moderator Edit: Vidyaranjan | Updated SR details***
Accepted Solution
Pegasystems
CA
Issue was determined to be related to custom coding which was causing the sudden increase in above error msgs.
Pegasystems Inc.
US
Hello,
A transaction ID mismatch occurs when a database commit occurs and the ID for the current transaction changes, then the client sends a different transaction ID up with a request. Since we don't want to overwrite good data with stale, we can't allow that. It can occur for a number of different reasons, some of which may have been at the product level and requiring a hot fix, but many are at the application/customization layer. It's impossible to say which this would be without further investigation.
I would start by getting HTTP debugging logs of the transaction ID mismatch occurring and then look at the exact error in the log file to try and understand what happened. If this worked in 6.2 but not 7.2, there are a couple scenarios I'd be mindful of...
- The OOTB activities called have changed and your custom code needs to be modified to work with the new paradigm.
- You were calling more than one action at a time and the performance changed. We don't guarantee that they will be called serially so perhaps you think your button click does A, then B, then C, but for whatever reason, in 7.2 on occasion you see A then C then B. If C changes the transaction ID, then B will fail with this error.
I hope this helps.
Thanks,
Mike
Pegasystems
US
One thing that would be useful to determine is whether you had more success on 6.2sp2 than 7 .2.1 because 6.2sp2 didn't bother to check the transaction id, or whether the timing of your overlapping transactions changed.
However, whichever is the situation, if you are using finish-assignment as one of several actions for a particular button or link, you'll want to have that action be the last one in the set since you know it will change the transaction id, so other actions for that button or link can fail.
I don't think it would be a good idea to attempt to come up with a "fix" that would make buttons and links that "happened" to work in 6.2sp2 work in 7.2.1. It's best to analyze your failure and fix it at the application level.
Pegasystems
CA
Thanks for the responses Mike and Eric! Definitely understood that custom coding and order of action execution is likely the cause of most if not all of the errors. This has been the solution path applied for previously seen issues, but they did each require significant efforts to determine and resolve. Because the application code base is large (tens of thousands of rules); the inquiry into reversion to Pega 6 functionality is to reduce the rework needed, and is being considered as there are no issues with the existing Pega 6 behaviour where sequential execution is in use.