My IF nodes containing a “matches regex” operator doesn’t behave as it used to.
I have a IF node comparing strings.
The left-hand operator is {{ $json.value1 }} and the right hand is abc|def
This used to be a match in previous n8n versions when $json.value1 is, for example, abc123.
It no longer matches.
What is the error message (if any)?
My regex are validated with regex101 Flavor python.
I tried other formats, but they all fail.
The n8n docs and chatbot cannot confirm what exact regex format is expect by n8n for the “matches regex” operator.
I can’t figure out how to proceed, can someone please give me pointers?
Thanks!
Hi @jb8n
I’d say n8n is expecting JavaScript-style regex here, not Python regex, so if I wanted abc123 to match, I’d try ^(abc|def) instead of just abc|def. If I wanted it to match anywhere in the string, I’d use .(abc|def). instead. Since there have also been recent reports about | behaving oddly in matches regex, I wouldn’t rule out that this is partly a product issue as well, not just your pattern.
@Benjamin_Behrens see screenshot above, /abc|def/ doesn’t work either.
I think your comment about adding a /i flag is also worth providing a better documentation on n8n regexes, since there’s also a node option “Ignore case”: which flags are accepted by n8n regexes? Which have precedence over node options? Why are square brackets necessary when they are not in regex101 with flavor Javascript? etc.
In regex, square brackets defines a character class, so it matches individual characters, not full alternatives like john doe|alice|bob. If you want alternation, I’d use parentheses instead, for example ^(john doe|alice|bob) if you want the string to start with one of those values, or .(john doe|alice|bob). if you want to match them anywhere in the text. So thanks for calling that out — the brackets would definitely change the meaning of the pattern.
That’s indeed a bug, already reported a month ago: | (OR operator) in regex not working in Switch node · Issue #25971 · n8n-io/n8n · GitHub
The pipe (|) character seems to be saved by the UI as a newline, breaking the regex.
It also explains why similar regex with a pipe character are behaving as expected in my older workflows that I didn’t touch in a while.
A workaround mentioned there, that I can confirm works for me, is to set the right operand as expression instead of fixed
