Avoiding endless loops on Jira issue events

Forge Forge Modules and Product Triggers
, , ,
1

Hi, first time writer, long time reader here.

Even though it feels like this should be an already solved problem, I haven’t been able to find anything that really fits my situation.

The background

  • I’m trying to sync multiple boards across multiple platforms (Github, Gitlab and Jira).
  • I have written a small forge app that uses an issue event listener to send messages to a central webhook which handles the synchronization across platforms, once a user creates or updates issues in Jira.

The problem
This works fine as long as all changes originate from Jira. Once an issue on another platform (e.g. Github) spawns an update event, the API call to my Jira project will update the issue.
This itself triggers an issue event within Jira, which will spawn another message that will be send to my central webhook.

The workaround
To avoid spawning issue events for changes caused by API calls, I have added a webtrigger to my forge app which parses the incoming REST call and executes the issue update within the “asApp” context. This way I can set a filter on my product event trigger to ignore all events that have the self-generated flag set.

This works just fine. However, using webtriggers means that I now have to deal with securing those endpoints myself. As authentication hasn’t been added as a feature to forge webtriggers yet, I see REST API authentication as my only option.

To summarize, I want to:

  1. Listen for changes on Jira issues.
  2. Send events once changes occur.
  3. Be able to accept API calls which update an issue without spawning another issue event.

My question
What would be the recommended way of dealing with this situation? Would you go ahead and secure the webtrigger endpoint or is there a better solution which avoids adding a webtrigger in the first place?

1 Like
2

Have you tried ignoring an update if it doesn’t change anything? This will terminate an endless update loop. Yes, you will end up with an extra update cycle but if you ignore it when it goes back to Github, it stops there.

3

Hi @bobby, and welcome to the Atlassian Developer Community!

This has indeed been requested multiple times and even spiked by Atlassian already, but didn’t result in a solution yet - please watch and vote for the following issues to raise Atlassian’s priority to address this notable gap:

Cheers,
Steffen

1 Like
4

Hey @ryan , yeah that’s a totally valid option.
I do have a DB in the middle which is currently only used to map GIthub Issue IDs to Jira task IDs.
I have thought about taking the change set and storing it next to my mapping as a “last update” so I can compare it to incoming requests. I felt that this would be a little hacky but sometimes the simplest idea might be the best.

5

Thanks for the links @sopel . I’ll make sure to vote those issues.
Hopefully it will be added to the roadmap sometime.