Summary

jstests/change_streams/change_stream_response_deadline.js reliably fails when re-run against an already-running fixture while connected directly to a shard (bypassing mongos), via the implicit_direct_to_shard_connection.js override used by the change_streams_direct_shard_connection_passthrough matrix suite family (SERVER-135150).

Evidence

• Observed on a burn_in task (burn_in:change_streams_direct_shard_connection_passthrough) that repeats the test file 4 times against the same fixture: repeat #1 passes (15s), repeats #2-#4 all fail immediately (~1s), 100% reproducible across 3 separate CI patches.
• Failure: assert.neq(NumberLong(0), cursor.id, "Cursor must stay open after an empty batch") in the test's getMore loop – the cursor comes back closed instead of staying open after an empty batch.
• The failpoint-guarded CollectionScan::doWork() sleep (hangCollScanDoWork, delay 300ms) genuinely executes once per failing getMore (confirmed via slow-query log durationMillis:300), but PlanExecutorImpl::_handleResponseDeadline()'s log id 10290000 ("Interrupting long-running collection scan after configured deadline") never fires in the failing runs, whereas it fires reliably (dozens of times) in the passing repeat and in every local repro attempt.
• Not reproducible locally: 47+ local iterations (including a 15x --repeatTests run) of the same suite/test all passed.
• The mongo shell process is confirmed fresh per repeat (new connecting to: line, new implicit session, topology rediscovered), so this is not leaked shell/JS state – whatever differs between repeat #1 and later repeats must be fixture-side (the shared mongod/mongos process reused across repeats).

Hypothesis (unconfirmed)

Something about reusing the same shard-hosted change-stream cursor/session infrastructure across rapid repeated executions – possibly related to session or cursor lifecycle not being fully reset when a client bypasses mongos's normal cleanup path – causes the response-deadline interrupt mechanism to be skipped on the next run.