RefinementsList doesn't respect faceting case insensitivity

[jsutaria]

Description

Since typesense uses case-insensitive faceting, there often ends up being times where the facet counts are incorrect, and also occasionally duplicate facets (in different cases) will show up.

There's multiple situations where this bug surfaces, and has been seen previously for Algolia in cases where the routing/ui state holds a value with a different letter case from the facet value being passed around by the server. In my specific usecase, I'm working on building a refinements list that allows the user to hit "enter" to search the results before the results from the search have loaded. Our custom refinements list has a debounce on the search, preventing making an API request for every single character change, and thus the results from searchForItems haven't always loaded by the time we make a refine(facetTerm) call. However, upon refining, the user often sees that the value they typed in (which differs in case from the facet values) is incorrect.

The screenshot below shows that the request from the typesense client returns an expected value of 5 hits of "React" but the "REACT" selection option (or really item.count from useRefinementsList().items) is incorrect.

Steps to reproduce

Two following examples, first demonstrating the incorrect count, second demonstrating the incorrect
https://linux-commits-search.typesense.org/?commits%5BrefinementList%5D%5Bauthor_name%5D%5B0%5D=DAVID%20STERBA
https://linux-commits-search.typesense.org/?commits%5BrefinementList%5D%5Bauthor_name%5D%5B0%5D=linus%20torvalds

See screenshots below for facet counts.

Expected Behavior

Expecting to only see the selected value, with the correct count (using case insensitivity),

Actual Behavior

Metadata

Using react-instantsearch @ 7.0.1 and typesense-instantsearch-adapter @ 2.7.0.

[jasonbosco]

@jsutaria Like this comment suggests, could you normalize the facet values before indexing them into Typesense?

[jsutaria]

Unfortunately, normalizing them isn't really an option for us, as the casing for the facets isn't standard, and we'd love to be able to show (as hints), the actual value of the facet options. Could the instantsearch adapter possible handle the intermediate mapping of taking the selected facets -> response from the API?