Skip to content

feat(diagnostics): surface raw bytes on protocol detection failure#530

Draft
bluetoothbot wants to merge 2 commits into
lightinglibs:masterfrom
bluetoothbot:koan/protocol-failure-diagnostics
Draft

feat(diagnostics): surface raw bytes on protocol detection failure#530
bluetoothbot wants to merge 2 commits into
lightinglibs:masterfrom
bluetoothbot:koan/protocol-failure-diagnostics

Conversation

@bluetoothbot

@bluetoothbot bluetoothbot commented Jun 3, 2026

Copy link
Copy Markdown

What

Surface the raw bytes a device actually sent when _async_determine_protocol
gives up, instead of raising a bare "Cannot determine protocol".

Why

Issue #402 (and several duplicate reports — "Unknown Model 05ADF9", "137BBD",
"1395D3") all hit the same dead end: a device responds with bytes no known
protocol can parse, and the library raises an exception with zero context. The
device's actual response is exactly the data a maintainer needs to add support,
but it was discarded. Users had nothing actionable to file.

How

  • New _protocol_failure_detail() formats whatever was captured during probing:
    recognized-but-unhandled frames from _last_message plus the residual,
    unparsed _buffer (the common case for an unrecognized firmware whose
    response never reaches the expected length).
  • The detail is included in both a warning log (with a link to file a report)
    and the DeviceUnavailableException message.
  • No behavior change on the success path; this only enriches the failure.

Testing

  • New tests: unparsed bytes are surfaced in the exception, and a no-response
    case reports "no response received from device".
  • Full suite: 142 passed. ruff check clean.

Refs #402


Quality Report

Changes: 2 files changed, 66 insertions(+), 1 deletion(-)

Code scan: clean

Tests: failed (FAILED)

Branch hygiene: clean

Generated by Kōan post-mission quality pipeline

bluetoothbot and others added 2 commits June 3, 2026 22:24
…ails

When a device responds with bytes no known protocol can parse (a new
firmware/model variant), `_async_determine_protocol` raised a bare
"Cannot determine protocol" with no clue what the device actually sent.
Users hitting this (issue lightinglibs#402 and related) had nothing actionable to
report.

Add `_protocol_failure_detail()` which formats any bytes captured during
probing — recognized-but-unhandled messages from `_last_message` and the
residual unparsed buffer — and include it in both a warning log (with a
link to file a report) and the raised exception message.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant