Repository navigation
Inconsistent expression evaluation for nested expressions #1260
Description
Consider following case:
{{ "c" in ["a", "b"] }} // outputs false
{{ !("c" in ["a", "b"]) }} // also outputs false
{% set categories = ["a", "b"] %}
{{ "c" in categories }} // outputs false
{{ !("c" in categories) }} // correctly outputs true
I'd expect expression evaluation to behave the same both for versions - with or without variables used, but it does not.
I've tracked this down to what i believe is a bug in parser
jinjava/src/main/java/com/hubspot/jinjava/el/ext/ExtendedParser.java
Lines 305 to 316 in 43bbea7
If there is a coma between ( and ) token parser will interpret it as a tuple declaration and otherwise as nested expression. However this seems incorrect in the above case as I am not trying to declare a tuple, just using a list literal in nested comparison
Activity
ZayanKhan-12 commentedon Jul 27, 2026
I tried to reproduce this on current
master(at the tip as of 2026-07-26, JDK 21 toolchain) with a plainnew Jinjava()and got the expected results for all variants:{{ "c" in ["a", "b"] }}false{{ !("c" in ["a", "b"]) }}true{% set categories = ["a", "b"] %}{{ !("c" in categories) }}true{{ not ("c" in ["a", "b"]) }}trueSo the literal-list case appears to behave consistently with the variable case on master — tracing the
ExtendedParserLPAREN lookahead (lines ~301-316), the comma inside[...]is bracket-depth-guarded, so it doesn't trigger the tuple path there. Possibly this was fixed since the version you hit it on, or the failing case needs additional context (a specificJinjavaConfig, or the expression nested differently). If you can share the jinjava version/config that reproduces it, happy to dig further; otherwise this may be closeable.(Analysis done with AI assistance; the table above is verbatim output from a JUnit run against master.)