[SOLR-17369] FunctionQParser's $param derefrencing ignores flags: breaks two arg vectorSimilarity() function for BYTE fields when constant vec is param ref

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: main (10.0), 9.7
• Assignee: Chris M. Hostetter
• Reporter: Chris M. Hostetter
• Created: 12/Jul/24 23:20
• Updated: 25/Oct/24 17:18
• Resolved: 22/Jul/24 22:06

Description

A coworker of mine recently ran into a problem that I believe stems from the way FunctionQParser recursively parses param references.

When it creates the subParser that it uses, it does not set it's current "flags" on that parser...

  protected ValueSource parseValueSource(int flags) throws SyntaxError {
...
    } else if (ch == '$') {
      sp.pos++;
      String param = sp.getId();
      String val = getParam(param);
...
        QParser subParser = subQuery(val, "func");
        if (subParser instanceof FunctionQParser) {
          ((FunctionQParser) subParser).setParseMultipleSources(true);
        }
        Query subQuery = subParser.getQuery();
...

One practical problem this causes, that i've seen "in the wild", is in the 2 argument variant of the vectorSimilarity function, where the VectorEncoding of the first arg (the field name) is used to set a flag on the  FunctionQParser  when parsing the second arg (which may be a constant vector)

So something like this works fine, for either FLOAT32 or BYTE fields...

q={!func}vectorSimilarity(my_vec_field,[1,...,2,3])

But using a param reference like this...

q={!func}vectorSimilarity(my_vec_field,$raw_vec)
raw_vec=[1,...,2,3]

... parses the raw_vec param as a ConstKnnFloatValueSource (the default) even if my_vec_field uses BYTE encoding.