It seems like we could filter the issues ourselves, but the query only returns the 50 first issues. If the GH id doesn't match, then a new issue is created although a matching Jira ticket could be found beyond the first hits.
My workaround for this was to move the Jira query https://github.com/coreos/issue-sync/blob/master/lib/issues.go#L40inside the following GH issue loop, so we can query Jira one GH id at a time. I didn't see any major performance hit and the script stopped creating duplicate issues to Jira.
When comparing Jira and GH issues during an update, the code queries issues from GH and then tries to find the matching issues from Jira. But, if there are many GH issues then this branch is executed: https://github.com/coreos/issue-sync/blob/master/lib/clients/jira.go#L130.
It seems like we could filter the issues ourselves, but the query only returns the 50 first issues. If the GH id doesn't match, then a new issue is created although a matching Jira ticket could be found beyond the first hits.
My workaround for this was to move the Jira query https://github.com/coreos/issue-sync/blob/master/lib/issues.go#L40 inside the following GH issue loop, so we can query Jira one GH id at a time. I didn't see any major performance hit and the script stopped creating duplicate issues to Jira.