The only reason LateParsingQuery exists is for the percolator... Because queries are parsed at index time and we want to resolve now at percolate time. We could hack to make it work here (just invoking rewrite in query is instance of LateParsingQuery in SpanMultiTermQueryParser#parse) but that doesn't feel right to me.

Rather what I'm leaning towards to, is to just forbid the usage of now in the percolator. This way we don't need to LateParsingQuery work around any more. (unless there is a better solution here)

Thanks, I have the feeling that the now option in percolator is quiet useful and people wouldn't like removing it. What are the other downsides of catching this special case in the parsing step and then rewriting it?

Thanks, I have the feeling that the now option in percolator is quiet useful and people wouldn't like removing it.

I have the same feeling :(

What are the other downsides of catching this special case in the parsing step and then rewriting it?

It adds complexity and the LateQueryParsing workaround is leaking to other places in the code base, but if we 're okay with catching this special case, then I think we can go for it. We should just put a big comment on top of that if statement.

This if statement should make the test pass:

if (subQuery instanceof DateFieldMapper.DateFieldType.LateParsingQuery) {
   subQuery = ((DateFieldMapper.DateFieldType.LateParsingQuery) subQuery).rewrite(null);
}

(Also LateParsingQuery needs to be made public)

Okay, such SpanMultiTermQuery (with nestes date RangeQuery) would not work with now in percolator then, or rather have now fixed at the moment of rewrite?

Tried to make test pass with the suggested workaround, but now test complains with java.lang.IllegalStateException: field "date" was indexed without position data; cannot run SpanQuery [...] at org.apache.lucene.search.spans.SpanWeight.scorer(SpanWeight.java:98) which makes perfect sense because I cannot see why a date field would have positions. Maybe it makes sense to not allow this kind of range query inside a Span Query and we should reject it? One would have to look at the mapping of the field though. I guess Range queries on numeric fields in this context also don't make much sense?

I agree @cbuescher probably disallowing it is the best way forward at least for now

On the query refactoring branch we now decided to reject SpanMultiTermQueries that wrap inner queries that don't produce MultiTerm lucene queries like the date field RangeQuery, so I'm closing this PR.