Jira Expression of the week — Pushing the limits

Photo by vikram sundaramoorthy on Unsplash

This week’s article concludes our series on Jira Expressions. Over the last weeks, we have looked at a lot of different expressions and you have hopefully become as convinced as we are that Jira Expressions are one of the coolest new features in Jira Cloud. But there is one topic left that we have to discuss:

The limitations of Jira Expressions and how they might affect you.

Do not worry, the limits have been set rather generously, so that you might never come up against them in real-life. Still, it’s good to know where the limits are. The documentation for Jira Expressions lists the following restrictions:

• Maximum number of results
• No more than 1.000 characters
• No more than 100 syntactic elements
• No more than 10 expensive operations

Maximum number of results

At most 10,000 primitive values or 1,000 Jira REST API beans will be returned. In most use-cases for Jira Expression, this limitation will not affect you at all and it is virtually a non-issue when using Jira Expressions for custom conditions and validators with Cloud Workflows. It can be more of a limitation when using Jira Expressions for data retrieval and aggregation (as we have done last week), so plan ahead and include some error handling in your scripts or use JQL if you expect high numbers of results.

No more than 1.000 characters

Just one thousand characters might sound low, but this limit is hard to hit in real life. The longest expression in this series was the data aggregation with a length of 154 characters. If we had tried to trim further down we easily could have pushed that number down to 127 characters. In any case, you will hardly ever get close to the limit, try cutting variable names to one letter — in the data aggreation example that alone would have shortened the expression by 17%!

No more than 100 syntactic elements

A syntactic element is pretty much anything that cannot be divided further.
This includes:

• Comparative operators like !=, ==, <, >
• Conjunction like || (or) and && (and)
• Accessing an attribute or a data point, like issue.created

As you can imagine this is also hard to hit, even though it is easier to come up against than the 1,000 character limit. Here is one (admittedly silly) example that would exceed this limit:

issue.id != issue.id || issue.id != issue.id || issue.id != issue.id ||issue.id != issue.id ||issue.id != issue.id ||issue.id != issue.id ||issue.id != issue.id ||issue.id != issue.id ||issue.id != issue.id ||issue.id != issue.id ||issue.id != issue.id ||issue.id != issue.id ||issue.id != issue.id ||issue.id != issue.id ||issue.id != issue.id ||issue.id != issue.id ||issue.id != issue.id ||issue.id != issue.id ||issue.id != issue.id ||issue.id != issue.id ||issue.id != issue.id ||issue.id != issue.id ||issue.id != issue.id ||issue.id != issue.id ||issue.id != issue.comments.length

As you can see, 100 syntactic elements should be more than enough for any use-case.

No more than 10 expensive operations

This is the one you are most likely to hit. Anything that loads additional data counts as an expensive operation. In practise this typically are comments, linked issues or sub-tasks, properties and customfields, loading any of those will count against this limit. Here is an example of how quickly this limit can be hit:

issue.comments.map(commentOfIssue => { 
    authorOfTheComment: commentOfIssue.author.displayName, 
    propertiesOfTheComment: commentOfIssue.properties.length
})

Whether the above expression will run successfully depends on the number of comments that have been made on the issue. Getting the issue is the first expensive operation, getting the comments the second one. Getting the properties of the comments counts as one expensive operation per comment. Hence, this expression will fail due to exceeding the limit if there are more than eight comments on an issue.

Conclusion

As we have seen, most of the limitations have been set so generously that they hardly ever will play a role in real life. Still, it is a good idea to test your expressions with different issues to avoid any surprises in production.