A bug in RTS is spotted in BF-40631:

Context: During eviction, we go through the update chain and pick the oldest visible update and write it to disk image (done in WT-15489). If the oldest visible update is unstable, the write this update to the disk image.

In RTS, we perform a btree walk through all pages. RTS can skip checking some unmodified (clean) pages if the on page/off page address's max durable ts is stable. However in-memory trees don't have an actual ref->addr so it bypasses these checks, making clean pages also being skipped even though they have unstable on-page updates.

This bug has always existed in RTS, however I think after WT-15489 we're more efficient in reconciliation so this is triggered more often. To trigger the issue, the entire page needs to be evicted and marked as clean with at least one unstable update, then not touched until RTS is called. I think this happens for index table and not for the record table because index entries are added with monotonically increasing keys (add a key X, then delete and insert another record at key X+1...) and the keys are not updated, only get deleted. This can lead to an entire page can be evicted and marked as clean, with the last few inserts being unstable. Whereas the record table is update heavy so the page would always be dirty so this bug won't be triggered.