CASSANDRA-20248: Fix failing repair test

[ifesdjeen]

No description provided.

[dcapwell]

what i don't get, why is this passing in trunk and been stable there, but cep-15-accord is unstable? What is unique about cep-15-accord that makes this unstable?

[dcapwell]

the fact this error is making it to this code path means we are not handling the error, and we have been since 4.0... why is cep-15-accord not handling this error anymore?

[dcapwell]

I found the root cause. CASSANDRA-20069 removed the error handling that this test depends on, so we need to revert that to get the test passing, not telling the test to ignore this exception.

jvm-dtest should do

# org.apache.cassandra.distributed.impl.AbstractCluster#uncaughtExceptions
InstanceClassLoader cl = (InstanceClassLoader) thread.getContextClassLoader();
get(cl.getInstanceId()).uncaughtException(thread, error);

this causes us to hit our failure detection logic, which leads to C* to halt the JVM due to stability issues (what this test is testing). Without that logic org.apache.cassandra.distributed.impl.InstanceKiller$InstanceShutdown doesn't get thrown and this test fails (because we stopped handling the exception that this test is trying to make sure we do)

[dcapwell]

this test looks to show that we stopped handling an exception we are supposed to handle, so telling the test to ignore it seems like the wrong behavior.

[ifesdjeen]

@dcapwell could you take another look? We do of course trigger killCurrentJVM. This logic was changed and improved, so we simply report this exception in addition to catching it:

                    AbstractCluster.this.uncaughtException(t, e);
                    stabilityInspector.accept(e);