Freezing monotonic time implicitly causes problems

[tzoiker]

I have faced the very same problem as in #383, but in another context and it was very painful to debug.

• I have used aiormq library to connect to RabbitMQ;
• It uses heartbeats to monitor connections and relies on monotonic time to set the time of the last heartbeat;
• Using freeze_time in some tests lead to the following:
  • Last heartbeat was set to event loop time;
  • freeze_time patched monotonic time;
  • Difference between the last heartbeat and the loop time became extremely large, leading to connection errors.

The problem was aggravated by the fact that I didn't pin the minor version of freezegun in the testing pipeline so that when 1.1.0 was released tests started to fail unexpectedly.

Some suggestions:

• Do not ever patch monotonic time implicitly for any module - it will most certainly break things. Adding asyncio to default ignore list will not help (there may be different event loop implementations) in all the cases which rely on continuous flow of monotonic time.
• Instead of ignoring specific modules, it should be possible to specify exactly what kind of "times" user wants to freeze, and once again, monotonic time should not be there by default.

Thank you for consideration.

[shughes-uk]

This also causes issues with celery during tests due to kombu relying on monotonic https://github.com/celery/kombu/blob/master/kombu/transport/virtual/base.py#L950-L965

Manifests as RuntimeError: Worker thread failed to exit within the allocated timeout. Consider raisingshutdown_timeoutif your tasks take longer to execute.

Workaround for now is we locked freezegun at 1.0.0

[ExpLog]

This causes all manner of problems with aiokafka as well, which are nearly impossible to debug, as it apparently just hangs when you give it timeouts.

Be very careful what you wrap with freezetime if you're using async.

My solution for now was to wrap factory fixtures with freezetime instead of wrapping tests.