There is a known gap in how WiredTiger enforces an API usage requirement related to timestamps and checkpoint.

When a user creates a checkpoint, they specify a timestamp at which all changes with timestamps less than or equal to that should be included, and no timestamp newer should be included.

WiredTiger checks that when a transaction starts committing, the timestamp chosen is valid compared to the stable timestamp. On the other hand, since WiredTiger does not co-ordinate transaction commit with checkpoint starting, a transaction that is in the process of committing may have a timestamp that should be included in a checkpoint, but not be included since the commit is still in progress while the checkpoint is running.

We should construct a test case that demonstrates that API issue.

I believe there is a nuance that might render this not possible. Since a checkpoint uses a pair of times, the timestamp and a transaction snapshot to determine what should be included. If the above race is present, the updates associated with a committing transaction will always be excluded based on the transaction ID check, and that would be the correct decision for checkpoint visibility.

Though it does indicate a bug in the application logic, and it would be nice to flag (somehow) that checkpoint didn't include an update the pure-timestamp version of time would have included.