Corruption detection is fragile?

[jpountz]

I was looking at how we detect corruptions, and the current logic tries to see whether the exception itself or any of its causes is an instance of CorruptIndexException. However, the following pattern that Lucene uses in multiple places:

Throwable priorE = null;
try (ChecksumIndexInput input = dir.openChecksumInput(fileName, context)) {
  // do some stuff that may throw any exceptions
} catch (Throwable exception) {
  priorE = exception;
} finally {
  CodecUtil.checkFooter(input, priorE);
}

causes the CorruptIndexException to be suppressed if some other exception was thrown in the try block. So the thrown exception would not be seen as a corruption exception. This makes me want to check for suppressed exceptions as well in ExceptionsHelper.unwrapCorruption but I don't know enough about corruption detection to know whether that is safe to do?

[s1monw]

I think we can expand the unwrapping to suppressed exceptions but I am not sure it will help much. Usually we will just detect it a bit later?

[elasticmachine]

Pinging @elastic/es-distributed

[ywelsch]

@jpountz @s1monw is this still something you think needs to be addressed, given that the corruption detection seems to be best-effort anyway?

[ywelsch]

This issue is causing pain across our test suite, see e.g. #41201
We will implement the workaround here (scanning for suppressed corruption exceptions).

[original-brownbear]

Workaround incoming in #41889 :)