Close popover
Jon Garfunkel (JonnyGar)
BNY Mellon
Vice President, BPM CoE
BNY Mellon
JonnyGar Member since 2009 91 posts
BNY Mellon
Posted: November 2, 2015
Last activity: April 7, 2017

Posted transaction id DOES NOT match record?

The error message "ERROR: posted transaction id '<md5 hash>' for frame 'pyWorkPage' DOES NOT match record '<md5 hash>' " is as old as PRPC.

Is there a full description of what it means, and what the ramifications are? Does it mean that the posted data is not saved? The log message should be more clear.

This is never accompanied by a stacktrace, but it would be helpful to know what for these what the activity called and pzInsKey/pyID of the case is.

A search for that returns numerous documents about multiple fixes along the way.

This appears in many releases over the years... SA-5031 points to one example in v6.1 sp1 in a grid click... and yet the displayed logs show this occurring in 2014. Was this fixed in v6.2? (We'll probably raise an SR to determine this).

We see this occasionally in production. Today a user clicked a button on a workform (with another form on a separate tab/thread) which called a few Ajax calls, ending with reloadSection(). Is it possible that reloadSection, upon getting an error response, might throw up a new window with a blank "Exception Details" (no message shown). The logs show nothing other than that error message.

Also, one way we've avoided this in custom Ajax calls is in not sending the transaction id at all. Where custom code is used, Pega's documentation doesn't stress very much whether to use it. From the help on the pega:url jsp tag:

"Used with a form and a Submit button, the transid option of the url tag can be useful to maintain synchronization between the servers state and the user's browser state. Ideally, such synchronization works even when a user clicks the Back icon in the browser window. ... When the browser state changes as the result of a user submitting an HTML stream, the pzTransactionID parameter stores the server state as it corresponds to the current browser stream, tracking where the user has been and where the user is. In some situations, it is important that the browser state and the server state correspond accurately. In situations where the server state data is not relevant, you can omit the transid option." [emphasis added].

Sure, it can be useful. In which situations?

I searched transid. Here's a question I asked in 2010, never unanswered:

Basically, since it takes more work to remember to include <option name="long"> within <pega:url>

When we're in Desktop (JavaScript) API, we have the SafeURL object - which has no mention of primary/transaction/frame at all. So it's just easier to skip this.

***Updated by moderator: Lochan to add Categories***

Case Management
Moderation Team has archived post,
Close popover This thread is closed to future replies. Content and links will no longer be updated. If you have the same/similar Question, please write a new Question.