algolia / instantsearch

⚡️ Libraries for building performant and instant search and recommend experiences with Algolia. Compatible with JavaScript, TypeScript, React and Vue.
https://www.algolia.com/doc/guides/building-search-ui/what-is-instantsearch/js/
MIT License
3.61k stars 505 forks source link

Refinement list items count is wrong in certain scenarios #5160

Closed flevi29 closed 1 year ago

flevi29 commented 1 year ago

🐛 Bug description

In refinement list when I select an item that has a high count number and an item that has a low count number, the item with the low count number will suddenly return a 0 count. This low count item is selected after facet searching for it, so normally it is out of the view when nothing is selected.

🔍 Bug reproduction

Reproduction repo: https://github.com/flevi29/refinement_list_bug

Live reproduction:

-

💭 Expected behavior

I expect the selected item with the low count to keep it's count.

🖥 Screenshots

-

Environment

Additional context

I thought to post this on react-instantsearch-hooks-web but initially I had the same problem with Angular, so I concluded it's an instantsearch.js bug

flevi29 commented 1 year ago

It's somehow specific to the collection within the repo, I am trying to recreate it with a simpler data set, but can't quite figure out what causes the issue.

Haroenv commented 1 year ago

Are you seeing exhaustiveFacetCount: false in the network response? That could be a reason for the behaviour

flevi29 commented 1 year ago

No, it's true. image

I updated and simplified the reproduction repo. With an Algolia free tier if you select Sík Sándor and then search for Sajó Géza and select it, it should happen.

Haroenv commented 1 year ago

Technically this is a behaviour of the engine, which doesn't forcibly return the facet which is selected to be shown. You can work around this by passing a high maxValuesPerFacet as such: <Configure maxValuesPerFacet={500} />, which doesn't significantly slow down the search (just 1ms in my testing with your dataset).

A real fix would be lower down the chain, where we should request the facet values in an extra query specifically for each of the individual applied filters, instead of the current logic where the refined values are requested in a single query.

Because of that, and the fact that this behaviour has existed for as long as faceting has had counts, I'm not sure that there could be a lasting solution for this yet.

Haroenv commented 1 year ago

As I don't see how this can fixed from our side, I'll close this issue