Post-function failed to progress an issue

[Helene Lund Engebø]

Hi, We are using jira workflow toolbox for several purposes in our workflows. One function progresses the issue from status resolved to status closed if the resolution set during the resolve issue transition is "Ok". This has worked without problems so far, on several hundreds of issues. However today one single issue failed to progress to status closed, even if the resolution was Ok.

So I am wondering whether maybe the order of the post functions is wrong, or if some kind of delay could have caused it? There are no errors in the atlassian-jira log. The issue type, assignee and project is the same as for many other issues that progressed correctly.

Any clues that could help us figure out why this happened?

JIRA version 6.4.12.

[Helene Lund Engebø]

Btw, the first post function is just a numeric counter, so it shouldn't influence this at all.

[Fidel Castro Armario]

Hi Helene,

After this failure, have other issues been transitioned correctly?

Have you tried to transition the same issue again? In case you did it, and it failed again, please do the following:

1. Set logging level for package com.fca.jira.plugins.workflowToolbox to DEBUG. You can do it at Administration > Logging and profiling > Configure logging level for another package
2. Reproduce the problem and share your log file with me. You can send it to [e-mail].

[Helene Lund Engebø]

Hi Fidel, And thanks for the quick response.

Yes, other issues have been transitioned correctly after this failure. The affected issue was reopened, then transitioned to resolved again, and in this case it did not fail.

I also should mention that the resolve issue transition (i.e. the transition which contains the post function) is in most cases done via the jira java API. Not sure if that could affect the order of events.

We will set debug logging and will contact you again if the problem is reproduced. Thanks again!

[Fidel Castro Armario]

The fact that the transition that contains the post-function is executed by JAVA API shouldn't have anything to do with the failure.

Does transition to PC_ISSUESTATUS_CLOSED contain a validator or condition that depends on the status of the issue that executes the post-function?

I don't recommend to keep DEBUG level in production server for long time, since it's very verbose, and so will throw tons of messages to the log file that might hide other problems in the server.

[Helene Lund Engebø]

Hi, There are no validators or conditions in this transition. I realised that we did not have any logging configured for workflow toolbox previously, so I have now set the logging to WARN. If we see that this behaviour starts occuring more, we will switch to debug temporarily.

Helene

[Fidel Castro Armario]

This problem might have some relation with Issue #324.

[Helene Lund Engebø]

This has happened for 6 issues (out of approximately 2000 resolved issues) during the last month. Unfortunately we don't have any entries in the logs; the server was restarted and we had only enabled logging through the interface. I will report back if it occurs again and we have any logging info.

[Fidel Castro Armario]

Helene, version 2.2.16 contains some modifications that could solve this issue. Please, reopen it in case the problems keeps happening after you update to the new version of the plugin.

[Helene Lund Engebø]

Thanks, I will! The bug has reproduced a couple of times since this report, but very rarely. So it's a little difficult to say whether it's resolved or not. But we will let you know if it occurs again even after upgrade.

[Helene Lund Engebø]

Hi, Unfortunately this still occurs. We haven't been able to upgrade workflow toolbox in the production environment until last week. We then upgraded to version 2.2.19.

The issue has occurred three times since then.

[Fidel Castro Armario]

Hi Helene,

Can you, please, provide the following data in order to study the cause of your problem?

1. XML export of your workflow.
2. The name(s) of the transition(s) which are failing.
3. The log file of your server.

You can send the information to [e-mail].

[Helene Lund Engebø]

Hi Fidel, I have sent the requested info to the email address.

Regards, Helene

[Fidel Castro Armario]

Thanks! I will keep you informed of any result.

[Fidel Castro Armario]

Hi Helen,

First of all, sorry for the delay in my response after receiving the information I asked you for. I have not found any clue about the cause of the problem, but I would like to try a simple change in post-function 2 of transition PC_TRANSITION_RESOLVE_ISSUE_DEFAULT (91):

1. Target field: Execute transition (delayed execution
2. Setting rules: (Ok)PC_TRANSITION_CLOSE_ISSUE_DEFAULT

With this change we ensure that the transition that is always being executed is PC_TRANSITION_CLOSE_ISSUE_DEFAULT, and not PC_TRANSITION_CANCEL_WO.

[Helene Lund Engebø]

Hi, Thanks, I will try that out on our test instance to begin with.

For the record, in all the cases I have seen of this bug, the transition PC_TRANSITION_CANCEL_WO has never been called instead. But still, it might be worth a try.

Regards, Helene

[Helene Lund Engebø]

Hi, We were finally able to update the workflow post function in the production environment yesterday, like you suggested above. At the same time, JIRA workflow toolbox was upgraded to version 2.2.29. The change has been running in several test environments for quite a while, without the bug being reproduced. Unfortunately in production, the bug still occurs, and it has happened quite a few times today. I might need to revert to the old method for the post function.

Could it have something to do with the volume in production compared to the test environments, given that the load is substantially higher in production? Any other clues?

[Fidel Castro Armario]

Hi @heleneresight,

The default delay when executing a transition in delayed mode is 500 ms (i.e., 0.5 s) after the transition were post-function is inserted has ended. JIRA Workflow Toolbox allows setting a custom delay using a certain sufix after transition name or transition status. For example, for setting a delay of 1 s we should use : {delay=1000}.

Please, try adding : {delay=1000}, or : {delay=750} if you find 1 s is too much. I think that it's very probable that it will solve your problem.

More specifically you should use:

(Ok)PC_ISSUESTATUS_CLOSED : {delay=1000}

or

(Ok)PC_TRANSITION_CLOSE_ISSUE_DEFAULT : {delay=1000}

[Helene Lund Engebø]

Thanks a lot, we will check this out!

[Fidel Castro Armario]

Hi @heleneresight,

Can we close this issue?

[Helene Lund Engebø]

Yes, you can close it. The increased delay has (almost) eliminated the problem. Thanks for your support.

[Fidel Castro Armario]

That you.