I can't find an answer to this question in the Adaptavist documentation: I want my transition to fail if my custom post-function script fails. Is there a return code that will cause the transition to fail?
Running a very simple test:
assert 1 == 0
causes the transition to fail with an ugly assertion message. Not what I want.
throw new Exception("Failure message")
does not cause the transition to fail.
Still looking for a way to cause my transition to fail.
The only way to "fail" a transition in a post-function is to crash it completely. It certainly is possible to write code that will always crash, but you really really do not want to be doing this.
Post-functions are not expected to break like this, they are expected to do things as part of a validated and successful transition.
If you crash out a post-function, you can easily corrupt your data, because part of the status change will have happened and other bits will not. Crashed post-functions are the number-one reason that people end up with issues they can't transition any more because they're in two different states and with corrupted data.
Never write a post-function script to fail. Write a validator script that checks if your post-function might fail, and fail there instead.
I'm not a groovy developer, so I can only think of an ugly way to do this... but maybe the ugly way would work, and I can't think of an alternative.
Have your transition with the post function actually be circular, so it points back to the same status.
Then, have a fast-track transition that executes after your circular one. The condition would be that the post function had to do whatever it did. If the post function failed, then the fast-track transition wouldn't execute.
The fast-track transition could also be setup with a condition so it's not visible to users and can only be executed through the automation.
Not knowing exactly what you're trying to accomplish with the post function, it's hard to know if the above would work, but this is one way you might be able to accomplish what you're trying to do.
I suspect the problem with the validator approach is that validators check to see if something is there, but the "something" in this case isn't "there" yet because the post function is what's doing the needful.
Yes, I've seen this a few times, mostly where the post-function needs to update a remote system and that can fail.
In the cases where you can't validate before acting, the usual resort is "flagging" - add some data to the issue that indicates "I tried to do this, but it failed". Almost always followed up with a service that searches for the flag being set and tries the remote update again, over and over, until it works (and then clears the flag of course). Similar to your looped transition function.
I will have to think about the validator function. I could test whether the actual step would succeed and notify the user in the transition if not.
@Nic I understand what you are saying about not have scripted post-functions that fail and leave the ticket in a unstable state. However, it would be possible for a decent workflow designer to come up with backout solutions. In my case, the post-function would be first in the list so that if it fails, nothing else would be done.
This is an interesting idea and I will have to think about it a little more. Thanks for suggesting it.
It looks like you're new here. Sign in or register to get started.
