mirror of
https://github.com/MarekWo/mc-webui.git
synced 2026-06-11 01:04:56 +02:00
MarekWo
13a650bb6c
The TimeoutError-based fallback added in 1d47c9c only fires when
mc.commands.get_channel() actually raises — but on a sluggish device the
call returns an empty/falsy event without raising, so the loop walks
all dm._max_channels slots (40 on the firmware in production), each
empty result returns None, and the API yields just Public (or whatever
slot 0 happened to succeed on). The DB fallback never triggered and the
user kept seeing just Public after refresh.
The channels table in the DB is already the authoritative cache:
- _load_channel_secrets() syncs it on every device connect and prunes
stale rows,
- set_channel()/remove_channel() update it synchronously with the
device,
- _refresh_channel_secret() refreshes individual rows on per-send
refresh.
Drop the device-slot iteration in cli.get_channels() and read from the
DB. /api/channels response time becomes a single SELECT (<1 ms) and is
unaffected by device responsiveness — exactly what we wanted from the
fallback in the first place.
Also revert the TimeoutError re-raise in get_channel_info(): the
console `channels` and `add_channel` commands iterate slots and would
crash on the first slow one. Logging + None on failure is the right
behavior for slot iteration. The 3 s default timeout stays since it
still keeps individual slot probes cheap.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>