Automations: Unclosed capture group in smart values condition regex

[Aaron DeVore]

I'm trying to match against the summary in issues as part of an automation. The summary is formatted like "Dev refresh 2024-09-23". This is part of an if component comparing two values with a smart value exactly matching a regex. I have tried these:

(Dev|Stage) refresh \d{4}-\d{2}-\d{2}

(?:Dev|Stage) refresh \d{4}-\d{2}-\d{2}

\w+ refresh \d{4}-\d{2}-\d{2}

These all pass the regex validator in the automation editor. They also work in online regex editors that I have tried. But when I run the automation, I see this in the audit log:

Invalid regex: Unclosed group near index 18 (\d{4}-\d{2}-\d{2}: String.match("(\d{4}-\d{2}-\d{2}")

[Aaron DeVore · Accepted solution]

I eventually found that the problem by rereading the audit log.

It is in a later step that captures a date using similar text:

Everything worked after closing out the capture group.

[Bill Sheboy]

Hi @Aaron DeVore -- Welcome to the Atlassian Community!

For a question like this, please post an image of your complete automation rule, images of any relevant actions / conditions / branches, an image of the audit log details showing the rule execution, and explain what is not working as expected. Those will provide context for the community to offer ideas. Thanks!

Until we see those...

IMO, I would not rely upon the rule editor not showing an error for a regular expression as a forecast it will work.  There are lots of community posts showing expressions which work in other editors / parsers which do not work in Jira automation rules with match() and condition checks.  And the documentation indicates the expressions are "based upon Java's Pattern class" but it does not state explicitly what is (or is not) supported.

Perhaps try the simplest possible expression that could work, test, and then incrementally improve that until it meets your needs or stops working.

Another possible cause of such symptoms is a parsing order problem in rules with regular expressions; that is, processing starts before the expression is parsed for things like escaped characters.  The workaround for that cause is to first build / define the regular expression as a created variable and then use that variable in the match().

Kind regards,
Bill

[Jim Knepley - ReleaseTEAM]

You probably already figured out that it's referring to the mismatched opening parenthesis before the date digits, so the question becomes "why is that being evaluated when it's not part of the regex I provided?"

That's a good question, and I don't have a good answer.

Working on the idea that that is a remnant of a previous version of the regex, I would maybe try to delete the old version entirely and recreate it from scratch.