Tim Owen created SOLR-15220:
-------------------------------
Summary: Json faceting allows val and count as stat/subfacet names
Key: SOLR-15220
URL: https://issues.apache.org/jira/browse/SOLR-15220
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: Facet Module, JSON Request API
Affects Versions: 8.8.1, 7.7.3, master (9.0)
Reporter: Tim Owen
The json faceting API allows you to name your stats or subfacets with the names
{{val}} or {{count}} which leads to confusing results or failed requests,
because these names are effectively reserved by the code that builds the bucket
responses.
We noticed this by accident, when some new client code used the name {{count}}
for a stat and we were getting unexpected results. What seems to be happening
is that the NamedList from each shard contains *both* the true count and our
stat value under the same key. Both NamedList and JSON/XML allow duplicates so
there was no failure at this point. Then in distributed mode, the facet merger
combines the values from both keys, and we ended up with the overall response
having an inflated number for our stat.
I think we could just validate against those 2 names being used for stats or
subfacets, in the facet parser {{parseSubs}} method, to avoid this situation. I
would rather know it's asking for trouble than allow it and get weird results
or an exception. There may be other reserved names, it depends on the facet
type used. Alternatively we could throw an exception if a duplicate key is used
when building the NamedList response, although there isn't a central place to
check that.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
