ERROR: posted transaction id xxx for frame 'pyWorkPage' DOES NOT match record xxx
Hi All,
I am seeing too many following log entries in production system recently when users take action on cases:
ERROR: posted transaction id 'ceabb63b5125ea10be261035b5ddeb8f' for frame 'pyWorkPage' DOES NOT match record 'e9a20dd2b5c6a09235918389dd60f933'.
I searched on PDN and found that there had been a a Hfix provided for 6.2 sp2(https://pdn.pega.com/support-articles/error-posted-transaction-id-does-not-match).
But my application is on 7.1.5. So can someone please let me know if this issue is still exists in v7.1.5 and if I can apply this Hfix? if not then what would be the solution to fix this issue?
Pegasystems Inc.
US
Looks like similar issues do exist even in pega 7.1.7: https://community.pega.com/support/support-articles/transaction-id-mismatch-interaction-post-upgrade-pega-71. If you know the reproduction scenarios, that would be great first step. Attach fiddler trace would be helpful as well.
Pegasystems
US
That error means you did a commit operation (which changes the transaction id) but didn't send the new id back to the browser.
Normally, the id is sent to the browser when the screen is refreshed or a new screen is drawn.
You could also have a race where something is sent back to your browser with the new id AFTER your browser tries to send something to the server with the stale id.
As Kevin mentioned, get a fiddler trace. Use the timing diagram feature that fiddler offers to see how your transactions are dove tailing. Search the results (fiddler has a nice search tool) for your old and new transaction id's.
Oh, one more thing: Notice that fiddler has a feature where you can keep only the last 100 transactions. This means you can leave fiddler on for several days for some user if you think it may take them that long to trip on the error occurring.
And lastly, if you are using https, don't forget to enable https decrypting from the security screen in fiddler. /Eric
JPMC
US
Thank you Eric Osman and Kevin Zheng for your response!! I will try to replicate same issue in lower environment and follow your instruction and run fiddler to find out transaction id mismatch. On PDN articles other than commit it seems it could also be due to non-auto generated controls as well. Will investigate and let you know our findings.
JPMC
US
To update you all....We are planning to upgrade to v7.1.9 next week, so we have put this issue on hold and will upgrade and see if we still get this issue and take action based on that.