The way we query indexes internally is incompatible with prepared transactions.

According to WT_CURSOR::search_near, it will return "the record matching the key if it exists, or an adjacent record."

On an index, given the keys "A1" and "B2", and a query for "B", it is completely within definition for search_near to return "A1" instead of "B2". In this example, the indexed value is "B" and the RecordId is 2, which we concatenate to form the key we insert into the WiredTiger table, "B2". We then are only able to query for "B", which is not the complete key.

That means if there is a prepared update on "A1", an update or delete on "B" (which first requires a lookup) may hit a prepare conflict, even though "B2" exists and is a closer match.

This is a concern on secondaries and initial-syncing nodes, because they may encounter prepare conflicts that did not occur on the primary. We should consider partially-reverting SERVER-40177 to ignore prepare conflicts.