When a developer observes the multi-timestamp constraint invariant fire, the first step is (unfortunately) add a bunch of logging to better understand the code path of how we entered into this dangerous state.

If we could automagically give some better context (in testing) that might help us save a step. I file this ticket with a (self-proclaimed) clever proposal:

1. In production builds – fire the invariant/fassert as-is today. On debug builds (or with a hidden setParameter) flip a bit on the WTRecoveryUnit.
2. Then throw a WriteConflictException
3. Instrument calls to WTRecordStore::insert/update/delete + WTIndex + setTimestamp (probably using our existing wt cursor helpers) to add debugging information to some member state when observing the "context bit" being flipped on.
4. When committing the transaction again, we either:
   • Hit the fassert again – see that the "add context" bit was already flipped to true – print out the debugging information then crash.
   • Don't hit the fassert again – see that the "add context" bit was flipped – crash because we should have the first time.

I also imagine we'd have to make sure to only try this when retrying WCE's internally. I'm not positive how multi-statement transactions behave, but presumably this idea wouldn't be applicable. Multi-statement transactions also have less worrying surface area in my experience as they (by design) only have a commit single timestamp associated with them.