Hello Atlassian Community,
In my Forge application, I have a function that is triggered on all “avi:jira:updated:issue” events.
There are around 1250 update events every hour. ~95% of them are filtered out at the very beginning due to their irrelevance but I need to process them anyway. The problem is that sometime the invocations fail with “Rate limited” error (see screenshot).
There are no log messages at all. Also I didn’t find any information about this error type in Forge documentation.
I assume there is some limit (something like “If the “avi:jira:updated:issue” event triggers handler A more then 100 times per minute then all exceeding executions will be immediately rejected with “Rate Limited” error”) but I need more precise information to know exactly what to do.
Question
Is there any information on what exactly causes this error? Will it help if I optimize the function to make less calls to the storage API, Jira Cloud API? However, if my assumption is correct and the amount of times the function is called within some time range is the limiting factor here then such optimizations will not help and I need to find a way to somehow make less function calls, isn’t it?
Hello @ValeriyBilinskiy
~95% of them are filtered out at the very beginning due to their irrelevance
Do you mean your Forge app is receiving all Issue updates events, then you are filtering them, or you have applied an expression filter to the Trigger module in your Manifest file that is doing the filtering?
Receiving every single Issue update event from a Jira Cloud instance has never been a good idea and is something that is frequently advised against doing due to the volume of events that can be sent. It’s best practice to only send or receive specific Issue update events or when other Issue criteria have been met.
1 Like
Hey @ValeriyBilinskiy
@anon96974232 has provided some good information around using expression filters to limit the number of events if possible.
The invocation rate limit is published here. Rate limited product events will be retried by the platform.
3 Likes
Hello @anon96974232
Thanks a lot for your response!
No, I don’t use expression filters. My function is executed on each issue updated event in Jira. As the first step, the function filters most events by comparing the incoming issue data with the expected data taken from storage.
I don’t use expression filters because, as I understand it, they don’t support dynamic configuration (or at least I didn’t find how to do this).
For example:
- The function should do some work if the “customfield_10123” was updated and the issue itself belongs to “TST” project. Otherwise, ignore the event.
This can be easily added as hard-code to the expression filter in the Manifest file.
- But what if you have a project “FOO” and “customfield_10333” for another app installation?
- What if the existing installation should switch the listening from “customfield_10123” to “customfield_10999”?
It’s not good if I need to rewrite and redeploy Manifest file on each new app installation or configuration change just to make the filtering work. Right now, the users need to just open configuration page and update certain fields to make the app work for their particular environment. That’s much more adaptive.
However, I will be very happy if I’m wrong and expression filters can take the values dynamically (i.e. from storage API) so that each particular installation use their own values to compare with.
Hi @SamSmyth
Thanks a lot for the information!
I though this information is not related to the Jira events processing 
Anyway, although I’m aware about expressions filtering I have concerns that it will work for my use-case. I described the situation in the response above.
I would be extremely grateful if you have anything to add and make the expression filtering work adaptive for >1 app installations with different configurations.
Hello @ValeriyBilinskiy
You’re correct, the Manifest file is immutable once you publish your app, so you can’t dynamically alter the expression filter (There was RFC-95 earlier this year that proposed dynamic Manifest modules and I think there’s an In Progress feature request in JAC for the same, so it might be possible in the future).
In the meanwhile, you said that a user could select a particular custom field for a particular project as the scope for your app to monitor. It that your app’s use case? If so, consider an expression filter that at least limits the Issue updated events to only those your app absolutely must have.
IE:
- If that field is not going to be on every single Issue type, then only include those Issue types it will be on.
- If there is some other field value of significant, such as Priority, Status etc, then only include Issues where those fields match those values.
This will at least partially limit some of the ‘noise’ before you do your in-app filtering.
Unfortunately, as far as know about Forge, you cannot listen to a custom webhook. If that were possible, you could use Jira’s REST API to create a scoped webhook with a JQL filter or fields filter that returned only the specific events you needed. This is what I do for my Jira monitoring apps, but these are all outside the Atlassian ecosystem.
That’s about all the advice I can offer on the topic 
3 Likes
