Symptom

A LIKE predicate in a WHERE clause whose match expression is not a field path fails with a bare AssertionError rather than a FeatureNotSupportedException.

select t.id from Thing t where 'abc' like '%b%'

throws java.lang.AssertionError with no message, from MongoAssertions.fail called by MongoAssertions.assertTrue in AstVisitorValueHolder.yield.

Cause

AbstractMqlTranslator.visitLikePredicate calls acceptAndYield on the match expression asking for the FIELD_PATH descriptor, with no isFieldPathExpression guard. An operand that is not a field path yields a different descriptor and the assertion fails: a string literal yields VALUE, and a dialect-supported function yields EXPRESSION.

The sibling predicate visitors in the same clause position all have that guard and throw FeatureNotSupportedException instead: visitInListPredicate, visitNullnessPredicate and visitBooleanExpressionPredicate.

ARCHITECTURE.md states that an AssertionError from MongoAssertions means an internal invariant was violated, and is always a bug rather than a legitimate response to user input.

Reachability

The string literal case has behaved this way since LIKE support landed, and is unlikely to appear in a real query. It becomes materially easier to hit once HQL string functions are supported, because a function operand then reaches the same line:

select t.id from Thing t where upper\(t.s\) like '%HEL%'

Fix considerations

Adding the guard turns the failure into a clean FeatureNotSupportedException. Worth deciding at the same time whether the following should remain unsupported, since both are expressible in MQL through an $expr filter and both currently throw a bare message with no tracking ticket:* where upper(t.s) in ('X')

• where upper(t.s) is null

Alternatively, we could just add support for this construct.