[LUCENE-6135] re-number fields randomly in tests

• Type: Test
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 5.0, 6.0
• Lucene Fields: New
• Assignee: Unassigned
• Reporter: Robert Muir
• Created: 24/Dec/14 15:42
• Updated: 28/Aug/22 14:22
• Resolved: 28/Dec/14 11:21

Description

Currently some code (such as stored fields bulk merge) depends upon consistent field number ordering.

In the case field numbers do not align, then optimizations are disabled, because the would cause crazy corruption where values are mixed up across different fields.

But this is hardly tested today. If i introduce an intentional bug into this logic, then only one lone test fails: TestAddIndexes.testFieldNamesChanged, and only about 10% of the time at best. In general tests pass.

--- lucene/core/src/java/org/apache/lucene/codecs/compressing/MatchingReaders.java	(revision 1647793)
+++ lucene/core/src/java/org/apache/lucene/codecs/compressing/MatchingReaders.java	(working copy)
@@ -52,6 +52,10 @@
     for (int i = 0; i < numReaders; i++) {
       for (FieldInfo fi : mergeState.fieldInfos[i]) {
         FieldInfo other = mergeState.mergeFieldInfos.fieldInfo(fi.number);
+        // nocommit:
+        if (true) {
+          break;
+        }
         if (other == null || !other.name.equals(fi.name)) {
           continue nextReader;
         }

Don't get me wrong, its a great simple test, but it should not be the only one doing this. And it would be great if it failed more often, i havent looked as to why it only fails rarely if there is a bug in this stuff.

But in general, we should simulate this more. My current idea is to shuffle up field numbers in MockRandomMergePolicy.