Major Description
Shamik Bandopadhyay noted on the mailing list that debugQuery=true wasn't returning info about how the query was being parsed in SolrCloud.
Steps to reproduce...
- startup a simple 2 shard solr cluster using the example configs
- Load this URL:
- http://localhost:8983/solr/select?q=Foo&debug=query
- note that the debug=query causes a debug block including "parsedquery" showing "title:foo"
- Load either of these URLs:
- http://localhost:8983/solr/select?q=Foo&debug=query&debug=track
- http://localhost:8983/solr/select?q=Foo&debugQuery=true (legacy short hand option for enabling all debug options)
- Note that the debug block exists, but only includes the distributed "track" options - the query parsing debugging info is not available
- index the sample data (java -jar post.jar *.xml)
- Load either of these URLs:
- http://localhost:8983/solr/select?q=Solr&debugQuery=true&fl=id
- http://localhost:8983/solr/select?q=Solr&debug=query&debug=track&fl=id
- Note that now we have at least one matching doc, and the parsedquery info is included in the debug block along with the tracking info
- Load either of these URLs:
- http://localhost:8983/solr/select?q=Solr&debug=query&debug=track&rows=0
- http://localhost:8983/solr/select?q=Solr&debug=query&debug=track&rows=0
- Note: even though we have a matching doc, since rows=0 prevents it from being returned, the parsedquery debug info again no longer works - just the track debug info
The work around, for people who want don't care about the newer "debug tracking" and what the same debug information as pre-4.7, is to enumerate the debug options (ie: debug=query&debug=timing&debug=results) instead of relying on the shorthand: debugQuery=true