nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Getting "Destination status could not be resolved..." error sometimes

David Leal_28ge8x

I reviewed the question: Destination status could not be resolved. If using a smart-value ensure this resolves to a numeric s, but I don't think it applies to my case. I am getting the error:

Destination status could not be resolved. If using a smart-value ensure this resolves to a numeric status ID or untranslated name for issues (with current status): DOPI-727 (In Progress - 3)

The rule I have is preventing transition an issue to IN PROGRESS if the issue is unassigned, so it transitions it back to the previous status. The problem I am getting is that sometimes it works and sometimes it doesn't for the same issue. Here is my rule, it seems to be large, but the logic is simple, just we need to consider different scenarios an message based on the issue type:

I highlighted the portion for the subtask. As you can see from the Automation log. Note: I added the edit condition for start date after the log execution, so you don't see this edit condition in the log. Subtasks haves standard workflow TODO<->IN PROGRESS< ->DONE. Allowing backward transition from current status to the previous one:

The first time the condition is triggered the rule successfully executed, when the user transitioned an unassigned issue from TODO to IN PROGRESS:

but the second time (about 15 mins after the previous trigger) failed. The rule was triggered when the user did the same operation. I got the error message:

Here is the issue history:

I highlighted when rule was triggered.

In this case, the workflow is the same, so I don't think there is workflow post-condition or function. The rule works because the first time for the same issue it worked, but for some reason it fails the second time and according to the issue history, nothing specific happened.

I am trying to find any specifics for the second case that justifies the fail, but I am not able to find it.

Any help is appreciated,

Thank,

David

Accepted answers

Tim C_i4lu7p

Hi David.

I'd suggest that its probably far more effective to add a "validator" into each of the workflows to check that the "assignee" field is populated when transitioned to "in progress" - rather than allow it to move forward and then automatically transition it back again?

Screenshot 2023-09-21 081937.png

All comments

Tim C_i4lu7p

Hi David.

Screenshot 2023-09-21 081937.png

David Leal_28ge8x

@Tim C thanks! This is a good advice, but then I depend on my Jira Admin, whenever I can, I try to solve it using Jira rule. The thing is that I was not able to find the pattern when it fails, other than it happens usually after a success execution, and the user latter tries again to transition the issue being unassigned. For example today it failed for the same issue after several successful executions.

Tim C_i4lu7p

Hi @[deleted]

You could try using "smart values" to capture the change in "status" values to double check on your possible routing options ...

{{fieldChange.fromString}} - Returns the previous value as displayed.

{{fieldChange.toString}} - Returns the new value as displayed.

You can simply record these smart values into the automation log using the "log action" event. This makes easier to track to find these type of slight differences in data between successive executions, etc.

Obviously, all types of data and customfields can be captured...

{{assignee.displayName}} - Returns the assignee

FYI. More info on smart values ...

https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/

Boldizsár Vermes

@David Leal, could it happen that when the automation rule started, the issue was already in Done status? It cannot be seen among the issue history events when the In Progress > Done transition happened compared to the rule execution. My guess that one wanted to put the issue into Done status and made the two transitions until there faster than the automation would put it back to To Do status.

Just two remarks:

I like helping people more than warning them, so in a case like this, assigning the issue to the person who made the transition instead of dropping back the status.

When I have to move the issue to a previous status, I mention the person who made the transition. It is easy to miss Jira notifications especially if noone is assigned to the issue.

David Leal_28ge8x

@Tim C at the end I asked my Jira Admin for help and we implemented validator in the workflow. This is more stable, and allows to send a popup message advising the user why the transition is not allowed, so I disabled the rule.

I logged the status value, actually I added a condition before roll back the transition to make sure it is a valid transition. Since it happens after several attempts the user tries to do a transition we don't want to allow, but again, I don't see the pattern, because sometimes it happens after the first, the second and third attempt. Something is odd here, and because the rule can fail after the third attempt then I don't see it could be an issue with the rule or the workflow itself, after every successful attempt the Jira issue on the same status, trying to transition to the next one, so why it succeed the first two times and fails the third one for example?

David Leal_28ge8x

@Boldizsár Vermes thank for taking the time to review my question. We only allow transition to the next status, there is no way to go from previous status to DONE, we don't allow such transition. It happened only when the rule failed, and it was not possible to roll back the transition, so the user continues until to reach the DONE status, but that is because the rule failed.

I am checking the history of the rule execution and for an issue that the rule didn't fail the first one was execute at: 09/21/23, 02:07:29 pm and the second time at 09/21/23, 02:07:59 pm, so even for this case within the same minute it didn't fail, then in the third attempt fails at: 09/21/23, 08:09:42 pm. Which is weird.

Assigning the assignee the user who does the transition is a good option, but it won't be a good approach for our case, because sometimes is the PO, the BA , or the person who runs the DSU who does the transaction (not the person who actually does the work. It is not the general case, but I don't want to assume that always the person who does the transition should be the assignee. I want also to educate my team that unassigned work should not be work in progress.

The rule is implemented for a program, several teams within the same Jira project, so at the end I have more than 15 people, I need to relay on rules and workflow conditions/validators because reaching each one of them when they try to do a non valid transition is not manageable.

David Leal_28ge8x

For example just looking to one issue (subtask) that executed successfully several times and then failed. Here the information with the time stamp.

This is the issue history:

Here is the log information in the automation rule:

then the failed execution:

as you can see the rule executed correctly three times for the same subtask, then in the fourth attempt if failed.

as you can see it is a weird situation why it works as expected the first three times then it failed.

Tim C_i4lu7p

HI @David Leal

Think I agree with @Boldizsár Vermes - its probably down to the exact timings and how quickly the rule runs compares to updating the status of the ticket (i.e. probably still at the original status and thus can't be moved back yet).

You could introduce a delay into the automation processing by using the "refetch issue data" event after the rule gets triggered.

You could then use {{issue.status.name}} and {{issue.issueType.name}} smart variables to double check the actual values and then use these as controls in your if/then statements.

As mentioned before - you should record these variables into the event logs to make it easier to de-bug and find these slight variances which aren't being handled in the logic.