The change made in bug 12430 to add the relevance ranking operator when using truncation with QueryWeightFields disabled can break searches that use st-numeric. In particular, consider Lexile number and range searches with "lexile-number,st-numeric" as the index. The following will not return results: /cgi-bin/koha/opac-search.pl?idx=lexile-number&q=600-650&weight_search=1 - This search becomes: (lexile-number,st-numeric=(rk=(600-650)) ) not Suppress=1 - ... which in RPN is: @not @attr 2=3 @attr 2=3 @attr 4=109 @attr 1=9903 @attr 2=102 600-650 @attr 14=1 @attr 1=9011 1 - ... and results in: Diagnostic message(s) from database: [117] Unsupported Relation attribute -- v2 addinfo '' In other words, mixing together the relationship operators for the numeric range search and relevance ranking isn't accepted by Zebra. However, casting it as CCL search explicitly does return results: /cgi-bin/koha/opac-search.pl?q=ccl=lexile-number%2Cst-numeric:600-650&weight_search=1 - This search becomes: (lexile-number,st-numeric=600-650) not Suppress=1 - ... which in RPN is: @not @and @attr 2=4 @attr 4=109 @attr 1=9903 600 @attr 2=2 @attr 4=109 @attr 1=9903 650 @attr 14=1 @attr 1=9011 1 - ... and gives back results. While arguably the Lexile number is better used as a limiter, in any event the query parsing should avoid trying to apply the relevance ranking operator to search clauses that intentionally use st-numeric. Noting that I observed this with Zebra; have not tested with Elasticsearch.