### Description of Bug #### Summary Since the per-controller SDK threads were added (b92a8996, "SDK Version 6 Updates"), a client that writes and then reads on the same connection can get the state from *before* its write. Clients on protocol 6 can wait for the new ACK packet. Clients below 6 have no ACK, so nothing restores the ordering they used to get. openrgb-python (protocol 4, used by the Home Assistant integration) hits this on every "turn on from Off": `set_mode("Direct")` re-reads the device, sees `Off`, and its following `set_color()` sends nothing because `Off` has no per-LED colors. The light goes to Direct but keeps its old color. Reads look correct, so it is very hard to diagnose. #### Versions - Broken: master `0b02dc62` (2026-09-30), also git `fd1bc449a` (2026-09-04) and `release_1.0` - Working: git `1e1fb09` (2026-07-05, protocol 5, before b92a8996) - Client: openrgb-python 0.3.6 and 0.3.7 (max protocol 4), Linux, Razer Goliathus #### Reproduction `race_test.py` (below) does Off → Direct → random color 20 times on one connection and checks the result with a separate client. | Server | Mode re-read right after `set_mode("Direct")` | Color applied | | --- | --- | --- | | master `0b02dc62` | `Off` 20/20 | 0/20 | | master `0b02dc62`, 100 ms sleep + `update()` before `set_color` | `Direct` 10/10 | 10/10 | | git `1e1fb09` | `Direct` 20/20 | 20/20 | | master `0b02dc62` + suggested fix below (local test build) | `Direct` 20/20 | 20/20 (openrgb-python 0.3.6 and 0.3.7) | With extra logging in `NetworkServer.cpp` the color packets that are lost never reach the server at all: the client never sends them, because of the stale mode it read back. #### Cause `NetworkServer::ListenThreadFunction` (`NetworkServer.cpp:1207`) now queues `UPDATELEDS` / `UPDATEZONELEDS` / `UPDATEMODE` / `SAVEMODE` / `UPDATEZONEMODE` to the controller's thread (`:1483`–`1531`), which applies them later (`ControllerListenThread`, `:1078`). `REQUEST_CONTROLLER_DATA` is still answered straight away on the connection thread (`:1310`). A data request that follows a mode change on the same socket therefore races the queued change. `SendAck` (`:3562`) returns early for protocol < 6, so older clients cannot wait. #### Suggested fix Keep per-connection ordering for clients below protocol 6. For example, apply their controller packets inline as before b92a8996, or have the connection thread wait until its queued packet for that controller has been processed before reading the next packet. I tried the first option in a local build: in the `UPDATELEDS` … `UPDATEZONEMODE` case of `ListenThreadFunction`, clients with protocol < 6 call the matching `ProcessRequest_RGBController_*` function directly with `header.pkt_dev_id` (under `controller_ids_mutex.lock_shared()`, as `ControllerListenThread` does), and only protocol 6+ clients are queued. The race test then passed 20/20 with openrgb-python 0.3.6 and 0.3.7, and the OpenRGB CLI client (protocol 6, still queued) kept working. Passing `header.pkt_dev_id` also sidesteps the queued path handing `this_thread->id` to `index_from_id()`, which treats it as an index for protocol < 6; that only works while IDs and indexes happen to match. #### Unrelated observation `ControllerListenThread` waits on `start_cv` without a predicate, and the enqueue side notifies after releasing `queue_mutex` without holding `start_mutex`. A notify that lands while the thread is busy would leave the entry queued until the next packet for that controller. I did not see this lose anything in these tests (every queued packet was processed), so it is only a possible issue. #### Downstream - Home Assistant: https://github.com/home-assistant/core/issues/182151 (1.0 compatibility) - openrgb-python could also defend against this (`Device.set_color` silently does nothing when the cached mode has no color support) <details><summary>race_test.py</summary> ```python """Reproduce: a write followed by a read on the same SDK connection returns stale state. Usage: python race_test.py HOST PORT "DEVICE NAME" Mirrors Home Assistant turning a light on from Off: set_mode("Direct") then set_color(..., fast=True). openrgb-python re-reads the device after set_mode and only sends the color if the re-read mode supports per-LED color. """ import random import sys import time from openrgb import OpenRGBClient from openrgb.utils import RGBColor HOST, PORT, DEVICE = sys.argv[1], int(sys.argv[2]), sys.argv[3] def find(client): return next(device for device in client.devices if device.name == DEVICE) def server_state(): reader = OpenRGBClient(HOST, PORT, "race-readback") device = find(reader) state = (device.modes[device.active_mode].name, device.colors[0]) reader.disconnect() return state client = OpenRGBClient(HOST, PORT, "race") device = find(client) tally = {} for round_number in range(20): device.set_mode("Off") time.sleep(0.3) device.set_mode("Direct") cached = device.modes[device.active_mode].name want = RGBColor(random.randint(1, 255), random.randint(1, 255), random.randint(1, 255)) device.set_color(want, True) time.sleep(0.3) mode, got = server_state() landed = (got.red, got.green, got.blue) == (want.red, want.green, want.blue) tally[(cached, landed)] = tally.get((cached, landed), 0) + 1 print(f"round {round_number:2}: mode re-read after set_mode = {cached:6} server mode = {mode:6} color landed = {landed}") print("tally (mode re-read after set_mode, color landed):", tally) device.set_mode("Off") client.disconnect() ``` </details> ### Attached Log Nothing is logged for this. At `--loglevel 6` the server only shows clients connecting and disconnecting: the lost color packets are never sent, because the client acted on the stale mode it read back. ### Operating System ~"OS - Linux" CachyOS (Arch based), kernel 7.2.8, OpenRGB built from master `0b02dc62` with `qmake6`/`make`, run as `--server`. ### Hardware Configuration Not device specific (it is in the SDK server). Reproduced on a Razer Goliathus; the setup also has a Razer Blackwidow Elite, Razer Goliathus Extended, Razer Mouse Dock Chroma, Gigabyte Z390 AORUS ELITE-CF and Logitech G703.