Large number of uncommited transactions

we are utilizing internal Scrip that on each “On Transaction” serializes that transaction to JSON and sends it to other tools for processing. This part works fine. What we have noticed is that there seems to be quite a lot of transactions that are probably uncommited, because when we obtain the transaction ID we are unable to view that transaction via REST API, we have also confirmed that it does not exist in the database itself.

One typical example is that clicking on the Correspond button and going to reply-page generates transaction that does basically nothing and is uncommited. The transaction (a new one) is created only after sending that correspondence. In total, it seems that simple correspond actions created 3 transactions on average, but only one of them is commited and actually does something / contains data…

This behavior creates unwanted strain on the processing tools, because for each transaction we have to check whether it actually exists (via REST API). Do you think it would be possible to check this on the RT side / turn it off?

To give more information, the serialization scrip runs in the batch stage, but I do not suppose that TransactionCreate stage would improve this. I will give it a try nonetheless

Which part of the action is your code running in, Prepare or Commit? The ticket update page does test runs of Prepare to determine who will receive email. This populates the “Scrips and Recipients” section. It then rolls back so no actual changes happen. If you’re running your code in Prepare, you’re going to see these, but if you run in Commit, you should only see your code running when the Correspond is actually sent.

Thanks, that was it! I was running it in the Prepare part of the action.

1 Like