Forge issue-updated trigger filter expression is not useful

Forge Forge Platform and Tools
1

Hi everyone,

I’m following up on my previous post (“Forge issue-updated trigger hitting rate limits…”) where I described encountering rate limits even when my function returns immediately.

The main recommendation from the community was to use filter.expression in the manifest to drop irrelevant events at the platform level. However, in practice the filter expression capabilities are so limited that implementing a meaningful filter becomes nearly impossible in my scenario:

Accessing App Properties
My app listens to a specific set of custom fields whose IDs are stored in app.properties and updated dynamically by a scheduler. Unfortunately, Jira Expressions cannot access App Properties for update events (as documented here: https://developer.atlassian.com/platform/forge/events-reference/product_events/#limitations).
Without access to these dynamic IDs, I can’t directly filter on the relevant fields.

Complexity Error (N × M)
As a workaround, I attempted to detect my fields by searching for a unique identifier string in the changelog:

expression: event.changelog.items.some(item => item.toString.includes('myIdentifier'))

However, this fails deployment with:

COMPLEXITY: Expression is too complex

because the analyzer evaluates this as an N×MN \times MN×M operation (items × string length).

Result

  • Without filtering → I hit rate limits due to high-frequency updates from other apps on the same site.

  • With meaningful filtering → I can’t deploy due to expression limitations.

Question

What is the recommended way to efficiently filter events when the target field IDs are dynamic?

Is there any viable pattern to perform string/identifier checks without exceeding the complexity limits?

Are there any plans to allow accessing app-level constants (e.g., app properties) within filter expressions?

5 Likes
2

In event filter, most of the usual Expression parameters are not available such as app properties, issue. You can receive list of changed custom fields but you don’t know what each one corresponds to (customfield_101101 ==> What is this field? We are only interested in fields configured in our app). How are we supposed to filter events here? If we can’t filter an unrelated event (most of them are), we are rate limited by update operations performed by another app. Because it generates lots of unrelated issue updates in the background.

1 Like