The checkpoint thread reads at the stable timestamp to evaluate the amount of oplog necessary for rollback. If a checkpoint is taken during server startup or after a rollback when we are reconstructing prepared transactions, it may be possible to hit an assertion like this in WiredTiger:
We have only seen this problem reproduce on the code coverage builder, which is extremely slow, and no users have seen this. This has also only been reproduced on 4.4, but it seems like it should affect every version from 4.2 to 5.1.
A workaround may be to take a global X lock while reconstructing prepared transactions to conflict with the checkpoint thread.