Details
-
Bug
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
7.7.3, 9.0, 8.8.1
-
None
-
None
Description
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.