We have added a volatile Throwable error field to AbstractBTree and AbstractHTree. This field is set if an error occurs during processing that would render the unisolated view of an index object as unusable. The primary use case (and the only case that is currently trapped) is an eviction of a dirty node or leaf that fails, e.g., due to a storage error, an out of memory error, an interrupt, etc. In these cases the index object becomes unusable and will refused some operations (notably you can not write on it).
This only effects unisolated index views.
We might extend both the set of conditions that invalidate the unisolated index object over time and also check the error field more frequently. For example, perhaps in getRoot() we can fail if the error field is set.
Change set is not yet committed. We are testing locally for correctness and performance regressions.