Missing Transition in Transition Track.

[PRAMOD KUMAR REDDY KASIREDDY]

Missing ABC transition in Test-1 (Ticket)  on 01.09.2022.
In history you can find the entry but not in transitions

[Nic Brough -Adaptavist-]

Could you explain more about what the problem is here?  I can't see anything wrong with your screenshots of limited bits of the issue.

[Jens Vogelgesang]

The last transition does not reflect the current status.

[Nic Brough -Adaptavist-]

So the issue is not Closed?

[Jens Vogelgesang]

Another example:

[Nic Brough -Adaptavist-]

Ok, that looks like a bug in the transitions display - it's reporting a transition that did not complete (as the status is still committed)

This needs to go to Atlassian for investigation - work through a support request at https://support.atlassian.com/contact (or, if you're on a free or starter licence, tell us here, because you won't be able to raise one)

[Jens Vogelgesang]

We export Jira via REST API into relational table, and also here this entry is missing.

There is a 2nd issue which is causing a similar problem which is tracked via:

https://jira.atlassian.com/browse/JRASERVER-28238

We get multiple transitions with the same timestamp. Those cannot be sorted without the knowledge about the transition sequence. I do not want to have such dependencies for all the clients using the data. This issue is from 2012 :-( and still not solved

[Jens Vogelgesang]

Any news?

[Jens Vogelgesang]

Any news ? The red marked are faulty in our system

[Nic Brough -Adaptavist-]

In the list of transitions, it's not hard to work out the pattern, despite the missing milliseconds - the issues have been transitioned in pairs.  Where you see

New Status	Old Status
Verified	Integrated
Rejected	Verified

The issue has gone Integrated -> Verified -> Rejected.  It's the same pattern in the rest of your data.

This is actually a bit of a "smoking gun" to me.

I can replicate it on Server using Scriptrunner.  Write a post-function that transitions the current issue again at the end of the current transition.  It does exactly what you are seeing!

If you could get read-only access to your database, you could prove that with the actual numbers.  It's five reads, but you might work it differently (and I've kept the SQL in English, because people have different dialects and preferences in the way they form their queries)

• Read project for the project-id for NCG3D
• Read jiraissue for the issue's id (project-id and 136205 are in two columns)
• Read changegroup for the the changegroup-id using the issue-id (you'll get a list of changes, with accurate date/time stamps)
• Read changeitem for all the lines with that changegroup-id, narrowing it down to just the status change data.  That should give you enough to find the matched pair of transitions with similar time-stamps. 
• Note their changegroup-ids and go back to see if
  • a) There's only one changegroup - definitely someone transitioning in a workflow
  • b) There are two changegroups with near-identical times.  Almost certainly someone transitioning in a workflow

[Jens Vogelgesang]

We have added a sequence Number to solve the problem with the millisecond.

This works fine, but still transitions are missing.

[Nic Brough -Adaptavist-]

That sounds like a botch to me.

What post-functions do you have in the workflow?