Guillaume Smet There was one right in the code snippet:

				// Likely a custom field bridge which does not expose the type of the given field; either correctly
				// so (because the given name is the default field and this bridge does not wish to use that field
				// name as is) or incorrectly; The field will not be added to the mapping, causing an exception at
				// runtime if the bridge writes that field nevertheless

And it's actually the only case I can think of. So it would be when:

• A given field has a field bridge
• This field bridge does not use (nor provide metadata for) the default field name
• org.hibernate.search.engine.metadata.impl.AnnotationMetadataProvider.determineNumericFieldEncoding(FieldBridge) fails to determine the numeric encoding
• org.hibernate.search.engine.metadata.impl.AnnotationMetadataProvider.isNumericField(NumericField, FieldBridge) returns true

If that happened, there would be a numeric field with unknown encoding, and generating the mapping for such field is impossible.

Now that I think of this, though, I wonder if this can even happen... I mean, this would require someone to put an @Numeric annotation on his field and to use a custom field bridge.
Before we fixed HSEARCH-2330 Resolved that was a valid use case, because it was about the only way to make the default field numeric when using a custom field bridge. Now, though, it doesn't seem useful at all.

Anyway, the comment above is not mine, so I'm not 100% sure why it was added. Here is the commit: https://github.com/hibernate/hibernate-search/commit/1450f9dd385ce810a09365beec02deba387d03af#diff-09eccad1a2093907e2d873d3193a4be7R309 I'd say maybe Gunnar Morling can help, but I doubt it given it's almost 1 year old...

If we decide that it's not useful anymore, then the solution to this ticket would simply throw an exception.