Debugging workflow transitions

Hi everyone, please pardon any ambiguities or confusion since this is my first post and I am new to being a JIRA admin. I've created a custom workflow and attached it to a scheme that a project is referencing. When I go and create an Issue Type (in this example, a 'story' issue type) and try to start the workflow, I am getting an error with the following message:

The start of my workflow is here:

I get the exception when on the "Not Started" state trying to click "Start Development" to transition to the "Dev Started" state.

Any help would be greatly appreciated! Thanks!

4 answers

We would need the transition definitions and post functions to understand what is breaking.

Not Started (1) Not Started Not Started Start Development (11)
>> Dev Started
Dev Started (2) Dev Started Dev Started Stop Development (21)
>> Not Started
Complete Development (51)
>> Dev Completed
Blocked (131)
>> BLOCKED
Suspend (451)
>> Suspended
Workflow Browser
Not Started
Start Development (11)
Dev Started
(Originating Steps) (Destination Step)

Post functions:

Set issue status to the linked status of the destination workflow step.
— THEN
Add a comment to an issue if one is entered during a transition.
— THEN
Update change history for an issue and store the issue in the database.
— THEN
Re-index an issue to keep indexes in sync with the database.
— THEN
Fire a Generic Event event that can be processed by the listeners.

My apologies. Is this sufficient information? Please let me know if there is anything else. Again, I appreciate the help and quick response!

Have you tried to rebuild your index to see if that is the problem?

Jo-Anne,

Thanks for the quick response. The only change I've made is changing the unit of tracking from minutes to hours. I am getting a message that states I should re-index but am curious as to how this could affect the workflow.

Thanks again for the help!

Hi,

I've just tried re-indexing (which took less than 10 seconds since we don't have many projects in JIRA) and am still receiving the original error. The re-indexing message is gone now.

Thanks.

0 votes

Ouch, that looks like a corrupted issue in the database. I see you've tried re-indexing, which is always worth a shot.

However, I'd run the integrity checker. This can correct entries in the database if they've been damaged.

If that helps, then it's worth thinking about the causes. In my experience, there are three main reasons

  1. Someone or something did a hard kill on the server running Jira. Anything from a "kill -9" to feeding the server coffee (don't laugh, I had a cat tip a mug down the back of my machine once. Can't blame anyone other than the idiot who left the coffee there though - me)
  2. Bad code - plugins can make a mess of the database, but they have to try really hard via the API. I guess core code could do it too, but I suspect Atlassian would have ironed those out well before version 2...
  3. Someone ran SQL against the database while Jira was running. (Find them and remove their access - you should never allow this. Reading is fine, but not write)

Hi Nic,

Thanks for the advice. I ran the integrity checker and everything passed successfully. I'll continue debugging with those reasons in mind. If you have any other ideas of how to debug this or where I can look, I would greatly appreciate it.

Thanks for your help!

Are you in a position where you can do a restore to yesterday's backup? Probably in a test environemnt. Just to see if it corrects the problem. You may lose a days work, but it is better than not being able to move forward.

Jo-Anne - I personally am not but will check with other members of the team to see if this is possible. Thanks for the suggestion.

Also, just to supplement my previous comment, here are the results of the Integrity Checker tool.

Hi, lunchbreak time, so I can attempt to give you some more things to check. Your post-functions looks good to me.

In the workflow designer

Here are some other things to check. When you click on "Not Started" and "Dev Started" it should highlight. Then click on the wheel(cog) to get the menu to display. Is "Issue Editable" checked? If not, make it so.

Now highlight the transition "Start Development" and then choose "View Conditions". You should see tabs across the top to show the conditions, validators and post functions. Do you have any conditions or validators set that could cause the operation to fail? If do not have a condition, then adding one.

Hi Norman,

Thanks for helping me out during your lunchbreak! I've checked all statuses and they are all "Issue Editable" except for "Closed" which we want to be in a final state. I also noticed that none of the transitions had any conditions so I added a "Assignee Only" condition to test. I've republished but am still getting the same error.

Do you have any other ideas? I greatly appreciate your help!

Hmm, By any chance are you using ORACLE as your database? It looked like MS Sql Server to me but just want to verify.

I would also try a group related condition if the issue was not already assigned.

I am assuming this is a new installation verses an upgrade, so please query(select) OS_HISTORYSTEP table to see what records exist in this table.

The only other idea is to try the system default workflow and see if the error occurs. If everything is ok, then copy and modify the copied workflow.

Hi Norman,

Thanks for your thoughts. We are using SQL Server. Your assumptions are correct, we've just installed JIRA about two or three months ago. I've also tried the system default workflow and the error is still occurring.

I've just received some word from Atlassian support when I opened up a ticket with them yesterday afternoon. I've sent them an XML backup of my database. I'll await their analysis and attempt to remove any duplicate entries. I'll update with the progress as soon as I can. Below is their response:

Hello Jason,
Thanks for contacting Atlassian Support!
Based on similar cases, I believe that the problem is caused by an inconsistency in the database. To be more accurate, with the <tt>os_historystep</tt> and <tt>os_historystep_prev</tt> tables.

There should be some duplicated entries on those tables and deleting those entries should be enough to fix the issue, however we can't confirm right now the implications of removing the data manually at the moment. With the XML backup will be possible to perform a deep analysis and provide an accurate solution for your problem.

We'll be waiting to hear from you on this case.

Cheers,
Arthur Gonçalves
Atlassian Support

Good to hear support is looking into your problem. Have a better day than the yesterday.

Yup, the integrity checker can find and fix these records when the data has slipped out of line, but it doesn't handle duplicates as far as I can remember. So finding and removing dupes is probably the way to do it, but very very carefully. I'm sure Atlassian will be able to tell you the best route.

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

2,760 views 11 18
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot