Steps to Reproduce

1. Create a new rule with a trigger you find most convenient (e.g. a Scheduled or Manual trigger)
   1. NOTE** Scheduled rules that run JQL which return more than 100 issues will also cause implicit branching. 
2. Add a Branch (Branch rule / related issues) that will require calls to Jira's REST API to find about 300 issues
   1. E.g. simplest way would be a branch with JQL that matches issues with a label of match-me
3. Inside that branch, add an Edit Issue action that makes the above JQL no longer match
   1. E.g. remove the match-me label on those issues

Example screenshot of a setup that caused the bug:

Expected Results

All 300 issues are edited. E.g. all 300 issues have the match-me label removed. i.e. running the same branch JQL in an issue search should now return 0 issues.

Actual Results

Some issues are not edited. I.e. some issues still have the match-me label. I.e. running the same branch JQL in an issue search will return some issues that never got edited.

Workaround

There is no complete workaround for this issue.

Something that help alleviate this issue is to effectively get the rule to repeat itself a number of times, so that most issues get updated. This can be done by copying the rule 2-3 times, effectively duplicating it, so that the chances that 100% of the issues are updated go up quite a lot. There are two important caveats to this:

1. This is still not guaranteed to update every single ticket. It just increases the chances, because the rules don't run at the exact same time, so they can eventually get through them all.
2. This can only be done if the Rule Actions are idempotent. I.e. if it's ok that these actions are repeated multiple times on a single issue. For example, an action that sets the status to Done is idempotent, because if you set it to Done 3 times, the outcome's the same as setting it once. Whereas an action that makes the Due Date 1 day later is not idempotent, because doing it 3 times will make the date 3 days later, as opposed to 1 day later.

Why does this happen?

• In order to find the issues to update, we call the Jira REST API with the JQL to match the issues.

• When there are more than 100 issues matched, we paginate our Jira REST API calls, 100 at a time. Let's say we originally matched 300 issues.
• By the time we get to our ~3rd page (this varies), we've already edited some of the original 100 (let's say 50 of them), and so now only 250 issues match in total, and so the 3rd page may only return ~50 issues, when in reality 100 should be returned.