The CollapseQParser has some very, very, old code/semantics in it that date back to when the FieldCache was incapable of differentiating between a document that contained '0' in the field being un-inverted, and a document that didn't have any value in that field.
This limitation does not exist in DocValues (nor has it existed for a long time) but as the DocValues API has evolved, and as the collapse code has been updated to take advantage of the newer APIs that make it obvious when a document has no value in a field, the collapse code still explicitly equates "0" in a numeric field with the "null group"
We can/should fix this bug so that the behavior is sane.
Known workaround for this problem: (redundantly) index a "string" version of the field being collapsed on - but this is a poor substitute fro being able to efficiently collapse on numeric fields (which take up less space on disk and in the collapse data structures)
- is blocked by
SOLR-15048 collapse + query elevation behaves inconsistenty w/ 'null group' docs depending on group head selector
- is related to
SOLR-15078 ExpandComponent treats all docs with '0' in a numeric collapse field the same as if null