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
Command queue: prioritize user commands over status polls #680
User commands and status polls share a single FIFO queue (asyncio.Queue in gateway_sessions.py). On busy systems or when the gateway is slow to NACK, a user action (e.g. turning on a light) can be delayed for several seconds while earlier status polls finish.
The is_status_request flag is already present on queued tasks, but it is not used for prioritization.
Current mitigations
Several related issues have already been improved:
These reduce how often the queue fills up, but the underlying FIFO behavior remains.
Proposal
Replace the plain FIFO with a priority queue:
User commands (and any frame with is_status_request=False) are dequeued first
Status requests are dequeued only when no user commands are waiting
FIFO ordering is preserved within each class
The existing “read-back after write” pattern must be preserved: a status request that is queued after a command for the same device must not overtake that command
Acceptance criteria
A user command queued while status polls are pending is sent before those polls
A status request queued after a command for the same entity still runs after that command
Existing tests for queue pacing and silent-zone skipping continue to pass
No regression on single-session gateways (MH200/MH201)
Activity
feat(gateway_sessions): prioritize user commands over status polls (O…
fix(gateway_sessions): handle putter cancellation cleanly, add deque …
fix(gateway_sessions): satisfy strict-typing ratchet and achieve 100%…
Merge pull request #685 from GreenGrassBlueOcean/feat/issue-680-comma…