Workflow Integrity Checks

[Harvey Bennett]

Hello Atlassian community,

I've noticed one of my Jira instances is having an issue on separate workflows across separate issuetypes where it randomly loses the workflow entry state. I have to now run the integrity checker to "check that workflow entry states are correct". This particular instance has a lot of consumers with a lot of tickets being created daily. These tickets sit in limbo. My question is where is the culprit area that is mostly commonly seen that causes this to occur? Sometimes it happens when the customer creates their first issue, sometimes it happens when their child task spawn. Again, no consistency on the workflow because we have different workflows and I've seen it occur on multiple ones. Our 3 most heavily used plugins for this instance is ProForma, Automation for Jira, and ScripRunner. Could it be one of those or is there another plugin that has been known to cause this?

If there isn't a clear answer has anyone crafted up a clever way to monitor if this happens? I have tried running a reindex on every issue that is created (because I have noticed the issue becomes unusable) but this doesn't seem to be working.

[Nic Brough -Adaptavist- · Accepted solution]

Much as I'm supposed to be an Adaptavist and hence Scriptrunner fan, that's actually the very first place I would look as it's the most likely thing on your list to be causing the problem!

The problem you are getting is because the issue's workflow state is held in two places in two different ways.  When there is a mismatch between them, Jira doesn't know what to do, and hence blocks all transitions.  The integrity checker fixes this.

I wouldn't worry about proforma at all, it doesn't go anywhere near the status, and Automation isn't built in a way that would allow you to do it either.

There used to be strings of bugs in Jira and some of the workflow extension apps that could do this, mostly with poorly written code, but they've mostly been fixed.  Jira rarely throws things into this state, it usually only does it now if someone kills the server or it loses the database connection at just the wrong time.  Most apps that used to have this problem have been fixed (or dropped off the marketplace)

But.  Scriptrunner lets you run scripts.  Without any checks that they are well written!  It is entirely possible to write a script that will cause the record mismatch.  A particular favourite is trying to directly write a status on to an issue, changing the end point of a transition or running a transition in a post-function.

So I would start there - look at all the scripted workflow functions on the create process and check the list of scripted listeners.  Are any of them touching status or trying to transition issues?

[Harvey Bennett]

Appreciate all the information Nic. The reason why I stated ProForma is because I've noticed the record can just become outright corrupted on creation. What happens is any data that was collected through ProForma just simply does not get attached to the issue but the PDF submission shows up with all the stuff they selected. I have noticed that these newly created records become "not transitionable" as well. It does happen when we use both our plugins to spawn subtask records as well. There are some fast-track post functions that are in there where I see the particular scenario up above I could see that causing a clash. I still don't understand how these first initial records get like this though? They go from that "Create" area right into the next status (that they are forced to go into and just sit there). 

Thanks again Nic.

- Harvey

[Nic Brough -Adaptavist-]

Ok, I'm not sure that Proforma has any direct impact on the status stuff, so I'm still wanting to check the scripting before worrying about Proforma.

Your mention of "fast track post functions" is another script type to check, and I'd completely forgotten that they can cause this.  It's not actually the scripts themselves, but if they're run in the wrong place - quite simply, check the create transition for where they appear in the list of post-functions - they must fall after ALL of the standard post-functions (index, fire event, etc), and I wouldn't recommend placing them before any other post-functions at all.