Description

TimeoutWatchdog.watch() waits for the watchdog to be enabled and then sleeps until the inactivity deadline. If a blocking addon hook disarms the watchdog during that sleep, the existing code can still invoke the timeout callback after waking because it only checks the activity deadline. On a live connection, that closes the client while the hook is still running.

I reproduced this with a standalone asyncio script that starts a local HTTP server and a regular DumpMaster proxy with tcp_timeout=1. An async request hook sleeps for two seconds; the client sends a GET through the proxy immediately after the watchdog enters its sleep.

• Before this change, mitmproxy logged Closing connection due to inactivity at 1.00 seconds and the client received EOF (b'').
• With this change, the hook completed at 2.01 seconds and the client received HTTP/1.1 200 OK with the expected body.

The watchdog now sleeps first and then waits for the event before checking the activity deadline (suggested in review). If it was disarmed during the sleep, it blocks until it's re-armed. Re-arming refreshes the activity timestamp, so the next check can't fire on a stale deadline and the loop doesn't spin. The final nested disarm() exit continues to register activity and re-enable the watchdog, and the configured timeout remains unchanged.

The regression tests cover:

• disarming during the watchdog sleep;
• nested disarms;
• re-arming without a busy loop; and
• activity moving the timeout deadline.

On unfixed main, the two disarm-depth cases failed and the activity-deadline case passed. With this change, all three cases pass.

Validation:

• uv run pytest test/mitmproxy/proxy: 467 passed, 4 skipped.
• uv run tox -e lint: passed.

Checklist

• I have updated tests where applicable.
• I have added an entry to the CHANGELOG.