You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
perf: use per-project Redis pubsub channels for WebSocket updates #78
The lint and index WebSocket endpoints (lint/ws, ontology/index-ws) both subscribe to a single shared Redis channel (lint:updates, ontology_index:updates). Every connected client receives every message and filters by project_id in Python:
With many concurrent connections, every client processes every message even if it's for a different project. This is fine at small scale but becomes wasteful at thousands of concurrent connections.
Proposed optimization
Use per-project Redis channels instead of a single global channel:
Note from #80: Both the lint and quality WebSocket endpoints currently use a 0.1s poll loop (pubsub.get_message(timeout=0.1) + websocket.receive_text() with asyncio.wait_for(timeout=0.1)), which causes unnecessary CPU wakeups per idle socket.
When tackling this issue, both WS endpoints should be refactored together to use concurrent coroutines — a blocking Redis listener and a blocking WS receive running via create_task / wait — so the connections only wake on actual events.
Activity
JohnRDOrazio commentedon Apr 14, 2026
Note from #80: Both the lint and quality WebSocket endpoints currently use a 0.1s poll loop (
pubsub.get_message(timeout=0.1)+websocket.receive_text()withasyncio.wait_for(timeout=0.1)), which causes unnecessary CPU wakeups per idle socket.When tackling this issue, both WS endpoints should be refactored together to use concurrent coroutines — a blocking Redis listener and a blocking WS receive running via
create_task/wait— so the connections only wake on actual events.feat: return 202 Accepted for pending quality jobs