Hello!

I ran into an issue (PYTHON-780) with deviation from expected cursor timeout behaviour (defined by SERVER-2212); if await_data=True then maxTimeMS is ignored. This is effectively undocumented (unspecified in SERVER-2212) where I assumed the following behaviour would be correct:

A query that completes in under its time limit will "roll over" its remaining time to the first getmore op (which will then "roll over" its remaining time to the second getmore op and so on, until the time limit is hit).

Without the ability to have controllable timeouts on the operation of tailing cursors I am forced to resort to polling behaviour to implement the timeout myself in Python. This is not a good solution for a wide variety of reasons, least of all for efficiency and added latency.

Use case: awaiting messages from distributed RPC calls over a capped collection used as a message bus. A specific example from my codebase is task.result(timeout=None) — return the result of the RPC call, waiting up to timeout seconds for it. (Indefinitely if unspecified.)

PYTHON-780 contains a minimal test case whose behaviour was expected to match the test_max_time_ms tests. (That is, raising of ExecutionTimeout vs. the current behaviour of silently finishing iteration.) Error code 50 is never returned over the wire protocol in this situation, as far as I can tell, thus never triggering this exception in PyMongo's _unpack_response code.