Moving this ticket to 5.6.0.CR1 on the current sprint, because the fix may be easy after all. I'll try, and if the fix doesn't work I'll move it back to 6.0.

Adding a link to HSEARCH-2393, where I had to fix a test (org.hibernate.search.test.query.sorting.SortOnFieldsFromCustomBridgeTest.testNumericCustomFieldLevelBridge()) and have been confronted with this issue again.

It seems that having a @NumericField annotation on the field, implementing MetadataProvidingFieldBridge in the custom field bridge, and re-defining the field type in MetadataProvidingFieldBridge.configure does the trick. One must not add a @SortableField annotation, though, or the world will fall apart with the Lucene backend (two doc values for the same field).
So to sum up, what we have to solve is the fact that adding @NumericField on the field with a custom field bridge is mandatory: it's utterly counter-intuitive, especially given that one must not add @SortableField.
One lead to achieve this: inspect the custom field bridge metadata before inspecting the standard field metadata in org.hibernate.search.query.engine.impl.AbstractHSQuery.validateCommonSortField(ExtendedSearchIntegrator, Iterable<Class<?>>, SortField). There might be other issues, though.

As a side note, when this ticket will be solved, it may be relevant to:

• revert https://github.com/hibernate/hibernate-search/commit/68d94e7c2b1acce4d6f6f4be01f05dbb1b4e7435

• adapt the tests added for https://hibernate.atlassian.net/browse/HSEARCH-1872#icft=HSEARCH-1872 so that org.hibernate.search.test.dsl.SortDSLTest.WrappedDoubleValueFieldBridge becomes a MetadataProvidingFieldBridge and uses document.add(new SortedNumericDocValuesField(name, doubleValue)); instead of the current luceneOptions.addNumericFieldToDocument( name, doubleValue, document );

It is also an issue for Elasticsearch as we end up with creating the wrong field in the schema: we don't take into account the information added in the MetadataProvidingFieldBridge and we suppose the information on the original field is the one we should take into account.

This is in relation with the idea we discussed in London to separate completely:

• the metadata used to build the indexed document

• the metadata of the structure of the indexed document

This would also allow to simplify a lot the schema generation of Elasticsearch as we could generate the Es schema directly from the structure of the indexed document instead of iteration through the fields, the field bridges, the class bridges and so on.

This is in fact blocking https://hibernate.atlassian.net/browse/HSEARCH-2261 as a test fails due to this issue if we remove the check which should be useless in the Es case.