Keep in mind that getFieldName() is supposed to return the facet name, and that the facet field is not indexed, only doc values are stored... Which means such a query will never work if:
The facet field has a different name than the source field (@Facet.name has been set to something other than the source field name)
or the source field is numeric (you would need a numeric range query instead of a term query in that case, see org.hibernate.search.bridge.util.impl.NumericFieldUtils.createExactMatchQuery(String, Object))
I think there is a few confusions in the code between the facet name (@Facet.name) and the source field name (@Field.name, @Facet.forField), and these confusions should be addressed.
I managed to reproduce the issues on one of my branches; see https://github.com/yrodiere/hibernate-search/tree/HSEARCH-2668
So, after having investigated a bit:
The case when we have a string field can be solved, see
Solving the case of numeric fields would require either to change the indexing format (add indexed text fields for the facet) or to have more metadata (have some way to convert the "facet value", which is a string, to a numeric value of the correct type
So I'll fix HSEARCH-2670, because I can, but I'll move this ticket to 6.0. Then will be able to consider the required breaking changes.