mirror of
https://github.com/zulip/zulip.git
synced 2026-07-12 21:04:41 +08:00
50356cc325
As best I can tell, this option was completely confused in two ways: * The name is confusing; it actually controls whether we _clear_ the timeout associated with the current handler * It's not clear why one would not want it to be unconditionally true. From reading the history, I'm pretty sure I had just misread the code when I created this. And this caused a real bug; a later refactoring caused us to basically never cancel the timeouts, which in turn resulted in 90% of all events traffic being hearbeats with a much lower frequency (~5s) than the intended 45s. Removing this code fixes that nasty bug. |
||
|---|---|---|
| .. | ||
| fixtures | ||
| lib | ||
| management | ||
| migrations | ||
| templatetags | ||
| tests | ||
| views | ||
| worker | ||
| __init__.py | ||
| context_processors.py | ||
| decorator.py | ||
| exceptions.py | ||
| filters.py | ||
| forms.py | ||
| logging_handlers.py | ||
| middleware.py | ||
| models.py | ||
| static_header.txt | ||
| storage.py | ||
| tornadoviews.py | ||