Sync issueLink between Server and Cloud failed in one or another method. How to fix this?

Originally asked by Hung Nguyen on 31 October 2019 (original question)


We had an Exalate connection going on between a JIRA Server and JIRA Cloud, where bugs are created fine from both side and sync-ed to the other side.
Now we want to add the sync-ing of issueLink between sites.
Here are what we did:
- Maintain matching set of issue link types between the 2
- In the server side connection, follow the instruction of
https://docs.idalko.com/exalate/display/ED/How\+to\+synchronize\+issue\+links\+on\+Jira\+Server
- In the Cloud side, follow the instruction of
https://docs.idalko.com/exalate/display/ED/How\+to\+sync\+issue\+links\+on\+Jira\+Cloud

Then JIRA Cloud reported error:
- “Issue already existed”, when we link 2 existing issues in Server, hoping it to link the corresponding 2 peer remote issues in Cloud

So I dropped the CreateIssue part in Incoming sync rule in Cloud, leaving only:
IssueLinkSync.receive(…)
then it synced correctly for existing issues

But then when I create a totally new issue in server, no issue link yet, then in cloud, it threw error at the above row, claiming the issue does not exist. so commenting it out, then the issue is created ok. But of course now, there is no issueLinksync any more

What is the correct way to do this?
Thanks
Hung
Source: Jira Server/Datacenter (old community)


Answer by Hung Nguyen on 18 December 2019

Can we limit the type of links that can be sync-ed?

Since it may happen that one side has more link types than the other, we wouldn’t want to see sync error if one side is adding a link that does not exist in the other side.

So safe-handling rule must be allowed here.


Answer by Hung Nguyen on 02 November 2019

If one side is using a linkType that does not exist in the other side, the sync will fail. is there any way to ignore in that case, don’t need to sync if the linktype is not an existing linktype in the remote site?


Answer by Hung Nguyen on 01 November 2019

I tried this, and:

  • For existing bugs, adding a new link will see the new link sync-ed over to the other sides successfully. This is expected.

  • But for creating bug on Server side, then in Cloud side the issue can not be created, the error is

       ..... Summary can not be null ...
    

Sounds like the issue.summary row was not applied.

So I copied the lines

  • issue.summary = replica.summary
  • issue.description = replica.description

from the Update section into the firstSync section, then the error went away. I just don’t understand why we have to have that duplication:

if(firstSync){
   // If it's the first sync for an issue (local issue does not exist yet)
   // Set project key from source issue, if not found set a default
   issue.projectKey   = "TEST"
   // Set type name from source issue, if not found set a default
   issue.typeName     = "Task"

   issue.summary      = replica.summary
   issue.description  = replica.description

   return CreateIssue.create(
     replica,
     issue,
     connection,
     issueBeforeScript,
     traces,
     blobMetadataList,
     httpClient,
     syncRequest
    ) {
  IssueLinkSync.receive(replica, issue, httpClient, nodeHelper)
 }
}
issue.summary      = replica.summary
issue.description  = replica.description
issue.comments     = commentHelper.mergeComments(issue, replica)
issue.attachments  = attachmentHelper.mergeAttachments(issue, replica)
IssueLinkSync.receive(replica, issue, httpClient, nodeHelper)



Is there any way to do better?

Thanks

Hung


Comments:

André Leroy-Beaulieu Castro commented on 01 November 2019

Hi Hung,

In a regular sync you would be able to only have the summary and description synced outside the first sync block because the first sync block gets executed and then the rest of the script gets executed as well so the summary and description are still being synced upon creation, but when you call CreateIssue.create(), that’s the exact moment where the issue is being created, and if the summary and description are not available to be synced before that, you will get that error.

Best regards,

André

Hung Nguyen commented on 01 November 2019

So from what you said. If I want to sync issueLink, there must be a change in the overall config, because for issueLink sync, we must call CreateIssue.create() ourselves and after that, all the other rules are ignored. If we don’t sync issueLink, then we don’t need to call CreateIssue?

André Leroy-Beaulieu Castro commented on 01 November 2019

Hi Hung,

It’s not that the other rules are ignored when you call CreateIssue.create(), it’s just that the issue can’t be created if the summary and description are not available before you call CreateIssue.create(), but the rest of what you said holds true, if you’re not syncing issue links, you don’t need to call CreateIssue.create().

Thanks,

André

Answer by André Leroy-Beaulieu Castro on 31 October 2019

Hi Hung,

Thanks for the question.

I believe the Jira Cloud side should look like this:

Data Filter:

IssueLinkSync.send(replica, issue, httpClient)

and Incoming Processor:

if(firstSync){
   // If it's the first sync for an issue (local issue does not exist yet)
   // Set project key from source issue, if not found set a default
   issue.projectKey   = "TEST"
   // Set type name from source issue, if not found set a default
   issue.typeName     = "Task"
   return CreateIssue.create(
     replica,
     issue,
     connection,
     issueBeforeScript,
     traces,
     blobMetadataList,
     httpClient,
     syncRequest
    ) {
  IssueLinkSync.receive(replica, issue, httpClient, nodeHelper)
 }
}
issue.summary      = replica.summary
issue.description  = replica.description
issue.comments     = commentHelper.mergeComments(issue, replica)
issue.attachments  = attachmentHelper.mergeAttachments(issue, replica)
IssueLinkSync.receive(replica, issue, httpClient, nodeHelper)

The Create issue part should only be executed in the first sync block, and the receiving of issue links should be executed on both creates and updates. Let me know if this sorts things out for you!

Thanks,

André