There is a bug where the read timestamp of the previous transaction can be used as the checkpoint timestamp.

A wiredtiger session opened a transaction with read timestamp TS1, and then a checkpoint made by the same session could be timestamped with TS1.

This problem was found by a test on standalone node (where stable_timestamp, all_committed should be 0 all the time) and an operation accidentally uses timestamp "1" as the read timestamp of the transaction. So this is probably an edge case.

I suspect the checkpointing operation probably reuses the same transaction struct as the previous transaction. The "read_timestamp" field somehow didn't get reinitialized so checkpoint was timestamped with that read timestamp.