romseygeek commented on code in PR #16891:
URL: https://github.com/apache/lucene/pull/16891#discussion_r4375482352
##########
lucene/core/src/java/org/apache/lucene/codecs/lucene90/compressing/Lucene90CompressingStoredFieldsReader.java:
##########
@@ -694,20 +695,23 @@ public void document(int docID, StoredFieldVisitor
visitor) throws IOException {
final long infoAndBits = doc.in.readVLong();
final int fieldNumber = (int) (infoAndBits >>> TYPE_BITS);
final FieldInfo fieldInfo = fieldInfos.fieldInfo(fieldNumber);
+ if (fieldInfo == null) {
+ throw new CorruptIndexException(
+ "Unknown field number: " + fieldNumber + ", docID=" + docID,
fieldsStream);
+ }
final int bits = (int) (infoAndBits & TYPE_MASK);
- assert bits <= NUMERIC_DOUBLE : "bits=" + Integer.toHexString(bits);
Review Comment:
OK, I think this was a leftover from a different version of the test that
tried to go through the whole `document()` API rather than hitting `readField`
directly. Bringing the assertion back works.
Perhaps we should try and clarify what these various assertions and
exceptions are trying to achieve? We want to test that we are writing and
reading data correctly, which is what the assertions are for. But we also want
to detect bit flips or bad disks or overwritten data in production, and
assertions can't help there. Maybe we should look at making the read side
throw plain IOException and IllegalStateException and move all the fine-grained
segment-level error checking stuff into CheckIndex? So production cases catch
general exceptions and can run CheckIndex if it looks like it's a data issue
rather than something like a network problem? And then CheckIndex gives us
nice error messages and points to individual segments and files.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]