We've encountered AF-4143 where the following assertion was triggered:

WT_ASSERT_ALWAYS(session,
  prev_upd->prepare_state == WT_PREPARE_INPROGRESS ||
    prev_upd->start_ts == prev_upd->durable_ts || prev_upd->durable_ts >= upd->durable_ts,
  "Durable timestamps cannot be out of order for prepared updates", );
I have been unable to reproduce this issue in our test environment. To gather more diagnostic information when this assertion triggers in production, we want to enhance the WT_ASSERT_ALWAYS statement in the durable timestamp check to include additional diagnostic information (start_ts, durable_ts, and flags) to help troubleshoot this failure.