Fix Script desync from Active Transactions/Rollback Contexts

[alexander_winkl]

Hello,

We are working through converting data from an external system by pulling the data through DB Connection on a series of Data Sources using a MID Server. We accomplish this by running a fix script (via the Proceed In Background option) that updates the SQL call on the first data source in our array, and then creates the import set record for that data source and imports the data using the updated SQL using the GlideImportSetLoader API, and then runs the transform map on the data source using the GlideImportSetTransformerWorker API. We have found that, at times, this fix script will show as Running on its Progress Worker but there is no Active Transaction, nor is there an In Progress Rollback Context, and instead the Rollback Context shows as Finished Recording.

Has anyone experienced this kind of desync before and know why it happens? The result is the transform history of the import set being transformed at the time of desync is stuck in a state of Running, but never moves on from this state since there's no longer an Active Transaction and the fix script (from a rollback context) thinks that it is "finished".

[alexander_winkl · Accepted solution]

Thanks for replying with these things to check! It turns out my issue was we had a long running SOAP Transaction that was causing one of our nodes to bounce. When the node bounced, it caused the transform to stall out because (as it turns out) transform workers can reach across nodes to do the transformation process.

So for anyone who finds this community post and is experiencing something similar, check to see if you have any other transactions on your environment that could be causing OOM errors and see if the issue still occurs after working through fixing those other transactions.