This is fallout from WT-10905. Besides the fix made in that ticket, there are other places where, while appending to either the insert list or update chain, we can set the new WT_UPDATE's next pointer to an aborted update or a tombstone.

That's bad for the same reason as in that ticket - a reader at the read-uncommitted isolation level cannot tell the difference between a committed abort from an old transaction, and an in-progress abort that's moving through the update chain. This means a function like wt_modify_reconstruct_from_upd_list can't correctly reconstruct a full update from a modify pointer, since it can't guarantee the same visibility as the writer did when calculating the delta for the modify.

The code in question is wt_row_modify (and I'm pretty sure wt_col_modify as well), where we choose upd_entry and pass that to wt_update_serial - we need to put a full value on the chain if this entry is a tombstone or aborted.

There might be other ways around this, but you'll need to be creative.