1
0
-1

We have 2 instances A and B where B can be used to write but is used mostly to read.

The scenario is the following:

  • Exalate triggers the syncronization of A-1 ... A-50
  • B-1 ... B50 are created on the B instance
  • Automation on B updates a custom field if the last change was done by the Exalate user
  • Exalate triggers updates for A-1 ... A-50 except that
    • In e.g. 2 cases, let's say B-1 and B-19, sync type is "EXALATE" so they do create A-51 and A-52.
    • The rest, they are UPDATE and those are smooth

In summary:

  • A-1 and A-51 are duplicates with the only difference that Reporter for A-51 is Exalate, and both linked to B-1
  • A-2 and A-52 are duplicates with the only difference that Reporter for A-52 is Exalate, and both linked to B-19

And we have to manually remove A-51 and A-52 so there are no duplicates.


Is this a known issue due to some racing conditions? Should we delay the automation for a few seconds so exalate has time to process the replies from B?

Thanks!

    CommentAdd your comment...

    1 answer

    1.  
      1
      0
      -1

      After a few tests, it seems that exalate needs a few seconds for the "linking" and these few seconds are the difference between the next update being considerede "Exalate" (a new creation that triggers the duplication) or "Update". Testing with the same set of 45 issues to synchronize we got this:

      • No delay: 4-5 tickets were duplicated
      • 3 seconds delay:  1 ticket was duplicated
      • 7 seconds delay: no duplications
        CommentAdd your comment...