Facet Collector is deterministic but in presence of a tie, choses the top facet using a non-trivial rule.

[fulmicoton]

low priority bug. (yeah those are rare)

When collection top K facets and in presence of a tie, we rely on the fact that facets are appended sorted by their "facet path" to solve ties elegantly : the first element of a tie with the tie count wins.

The problems with this method is that if the tie happens within the first k elements, (10, /facet/a) vs (10, /facet/b), 10 ends being the min count, and we happen an element with higher count (11, /facet/c), the logic that decides whether /facet/a or /facet/b will be removed from the top K, while deterministic, might remove either /facet/a or /facet/b. From the user perspective, we would like to keep /facet/a to keep the well-defined logic :
we return the top 10 facets, and in case of tie we keep the first according to the lexicographical order.

[hardikpnsp]

I am a bit new to Rust, would like to contribute to this issue. seems like I can change the implementation of Ord trait of Hit in order to support order by count and in case of a tie - order by facet.