max_time_ms_repl_targeting.js performs an insert, then attempts to read that value back with a maxtimems set against a secondary without satisfiable tags.

Part of the sanity check for that test includes running a query against the lone secondary (which absolutely should be able to pick up the record), but this races with replicating the write. BF-11945 illustrates the number of times we lose that race.

Changing the initial write to a w:2 write would ensure it's on the secondary when we got to look for it there.