transactions_target_at_point_in_time.js verifies sharded transactions with "snapshot" read concern target the shard that owned a chunk at the transaction's global read timestamp by starting a transaction, moving a chunk off an unrelated shard, then targeting that chunk and verifying a later statement in the transaction can still read from that chunk at the transaction's read timestamp by targeting the donor shard.

If the migration takes longer than the chunk history window (10 seconds), the multi-versioned routing table will no longer remember which shard owned the chunk at the transaction's global read timestamp, so the next statement will instead fail with StaleChunkHistory. This is the expected/desired behavior in this case, so the test should be able to tolerate this error by either retrying the operation at a higher timestamp (including the moveChunk) or by ignoring it.

–

Edit: Decided to just add a failpoint to the server to disable expiring stale chunk history and turn the failpoint on in the test.