Summary
When reconciliation detects that a page it lays out has a key-ordering problem, it discards the uncompressed image before panicking. Which makes it difficult to inspect the failure in detail.

We should ensure the image is available when the fatal error is generated.

Motivation

• Does this affect any team outside of WT?

No - this is additional diagnostic information.

• How likely is it that this use case or problem will occur?

It is extremely uncommon - which is why it's important to have good diagnostic information available when it does fail.

• Testing

This should be tested via deliberately corrupting an image generated by reconciliation, and ensuring the resulting core dump is useful. That test doesn't need to be automated.

• Documentation update

None

Suggested Solution

There is an easy way and a hard way for this change. The easy way involves understanding why the code introduced in WT-8466 added a comment saying {{ Return an error rather than assert because the test suite tests that the error hits.}}, and changing the decision, so that it's a fatal error at that point of the code.

The hard way is layering into the btree verify disk code the ability for a failure to be immediately fatal. I believe this is preferrable - since failing when the inconsistency is detected will be most useful for diagnostic efforts. On the other hand, it will likely require some restructuring to the code in bt_vrfy_dsk.c.