Title: Issue transitions being overwritten by Exalate after rapid status changes (Jira DC to Jira DC)

General Questions
,
1

Hi everyone,

We’re experiencing an issue in our Jira Data Center to Jira Data Center synchronization using Exalate, and I’d like to check if anyone has faced something similar or found a workaround.

Our setup:

  • We sync issues between a Jira Software DC project and a Jira Service Management DC project.
  • Both projects share the same workflow, and we want the statuses to stay in sync.
  • We use a technical user (e.g., Usuario_Sincronizador) to perform Exalate sync actions.

The problem:

  • When a user manually performs several status transitions in quick succession (e.g., Open → In Progress → Done), everything looks fine locally.
  • However, afterwards Exalate performs additional, out-of-sequence transitions on the same issue , using the sync user.
  • This results in the issue being moved backwards or to unintended statuses, as if Exalate is replaying old states from the queue.

This behavior suggests that Exalate might be applying outdated sync events after the issue has already moved forward.

Questions:

  • Has anyone seen Exalate apply state transitions after the issue has already been manually moved forward?
  • Could this be due to the sync queue processing delayed events, and if so, how can we prevent this from overriding the current status?
  • Would a replica.updated vs issue.updated timestamp check help here, even for status field?

Any advice would be greatly appreciated — especially on how to prevent old sync events from affecting the actual issue’s status.

Thanks in advance!

— Javier Fernández

2

Hi,

I think you are running into a conflict resolution problem.

If I have understood the problem correctly, I would point you here. Using the conflict resolution scripts you should be able to “instruct” exalate not to sync changes with older timestamps.

Hopefully this gives you some ideas.

Thanks
Majid