This is from BF-20193. The test is failing because a transactional read was blocked by tenant migration blocker and when if was unblocked the oldest timestamp was already moved forward by the wired tiger, thus read had to fail after migration was aborted. So this really happens by design.

Here the read fail:

[js_test:tenant_migration_concurrent_reads] 2021-02-13T14:11:25.265+0000 "errmsg" : "Read timestamp Timestamp(1613225479, 1) is older than the oldest available timestamp.",

here is the evidence that WT moved the oldest timestamp:

[js_test:tenant_migration_concurrent_reads] 2021-02-13T14:11:26.358+0000 d21522| 2021-02-13T14:11:26.357+00:00 D2 RECOVERY 23988 [SignalHandler] "Shutdown timestamps.","attr":{"Stable Timestamp":{"$timestamp":{"t":1613225485,"i":2}},"Initial Data Timestamp":{"$timestamp":{"t":1613225407,"i":1}},"Oldest Timestamp":{"$timestamp":

}}

My opinion we should simply fix the tenant_migration_concurrent_reads.js test here to allow the TransientTransactionError with oldest timestamp message. After all, we will fail the read anyway if the tenant migration will succeed (common case).

I'm leaving this as a new bug for someone to agree or disagree with my conclusion. If we keep it as a normal condition, the fix is 3 lines in the test.

To some extend my question is about migration design - does it make sense to block all reads for undetermined time if they will likely fail anyway? I understand that the user won't have much option than to retry anyway. But the retry may complete faster because if the new read will have newer timestamp it will not block.