Is it OK to deactivate the Auto Flush (sys_auto_flush) record for workflow contexts?

[GoBucks]

Is it OK to deactivate the Auto Flush (sys_auto_flush) record for workflow contexts?   I've read that older instances have this record.   Completed workflow contexts over 180 days old are deleted because of this record.   Newer instances do not appear to have this auto flush defined for workflow contexts, so I assume it is OK to set to inactive now?

Why did this exist at one time?

[Mwatkins]

Yes Jeff, that is correct. The record was there in older versions, is not there for new (z-booted) instances in Geneva through Istanbul, and has returned for z-booted instances running Jakarta. I have reached out to our development team to find out more about what happened. Should have an update for you soon.

[Mwatkins · Accepted solution]

Ok, Jeff, I have the answer now.

A long, long time ago, deleting the workflow context history led to an interesting problem with workflows starting afresh, years after the original flow completed. So, the Table Cleaner for Workflow Context was removed in Calgary - I did not realize it was so long ago. This was fine for a while but the flip side was that some heavy workflow customers started to see performance issues around the wf_context, wf_history, and wf_transition_history tables because they were growing so large. So, for Jakarta, we solved the original workflow restart issue and brought the workflow context cleaner back.

You can remove the Cleaner, but those tables will just continue to grow and the usefulness of the data in there is generally short lived.   If you delete it, or mark it inactive, you would own the record and wouldn't get our updates to it during upgrades.

So there is the long story.

Hope this helps!

[Uncle Rob]

Can ServiceNow comment on the nature of "we solved the original workflow restart issue"?

Seems to me the records don't have to be years old, but only a millisecond older than the flush interval, which pre-Calgary was 6 months.

[Mwatkins]

That's right Robert, it could be only milliseconds older than the flush interval. The determining factor is when the update to the target record occurs. I was attempting hyperbole when I said, "years after the original flow completed" - it didn't translate well to the written update. The problem record reference is PRB583095. Thanks.

[GoBucks]

Thanks for this information Mwatkins!   Ultimately, the restarting of new workflow contexts on pre-existing (often inactive) task records is an issue for us as well. So, good to hear that is fixed in Jakarta. (Regarding that, I'm unable to find PRB583095 that you referenced, let alone view it. Not that it's a big issue at this point...that was for the WF restart issue?).

Rather than messing with the auto flush record in our Helsinki instance at this point (and not on Jakarta yet) I do like the quick and fairly easy solution provided by rfedoruk. By just adjusting WF conditions accordingly as he stated, we can stop the unintentional workflow restarts on inactive records.

Aside from the WF restart issue, the fact that wf_contexts get cleaned up I don't think is an issue for us necessarily, especially if that is helping with performance, and at 6 months past their completion we hardly have reason to refer back to the workflow context. And I suppose if 6 months is too soon, that could always be adjusted, to 12 months, for example.