mirror of
https://github.com/zulip/zulip.git
synced 2025-11-02 21:13:36 +00:00
10ac671cd4
Apparently, we weren't resetting the query counters inside the websockets codebase, resulting in broken log results like this: SOCKET 403 2ms (db: 1ms/2q) /socket/auth [transport=websocket] (unknown via ?) SOCKET 403 5ms (db: 2ms/3q) /socket/auth [transport=websocket] (unknown via ?) SOCKET 403 2ms (db: 3ms/4q) /socket/auth [transport=websocket] (unknown via ?) SOCKET 403 2ms (db: 3ms/5q) /socket/auth [transport=websocket] (unknown via ?) SOCKET 403 2ms (db: 4ms/6q) /socket/auth [transport=websocket] (unknown via ?) SOCKET 403 2ms (db: 5ms/7q) /socket/auth [transport=websocket] (unknown via ?) SOCKET 403 2ms (db: 5ms/8q) /socket/auth [transport=websocket] (unknown via ?) SOCKET 403 3ms (db: 6ms/9q) /socket/auth [transport=websocket] (unknown via ?) The correct fix for this is to call reset_queries at the start of each endpoint within the websockets system. As it turns out, we're already calling record_request_start_data there, and in fact should be calling `reset_queries` in all code paths that use that function (the other code paths, in zerver/middleware.py, do it manually with connection.connection.queries = []). So we can clean up the code in a way that reduces risk for similar future issues and fix this logging bug with this simple refactor.