feat(transport): add WebUSB transport logging for firmware update diagnosis#710
Draft
feat(transport): add WebUSB transport logging for firmware update diagnosis#710
Conversation
Add comprehensive debug logging to WebUsbTransport for diagnosing firmware update issues (especially the 99% hang on Windows ARM64). Logs added: - connectToDevice: connection path, first-connect flag, reset errors - call: total packets count, send progress (every 10%), send duration - call: response wait time after all packets sent - receiveData: first packet typeId/length, total received packets - release: device release lifecycle This addresses a firmware update timeout issue where FirmwareUpload was followed by a 31-minute transferIn hang with no diagnostic info. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Contributor
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
Add connection deduplication in noble-ble-handler to prevent race conditions when two IPC CONNECT requests arrive simultaneously for the same device. The second caller now awaits the first's Promise instead of starting a parallel connection flow that causes service discovery timeouts. Also fix prettier formatting issues in webusb.ts logging statements.
Only print detailed send/receive logs for large transfers (>100 packets) or slow responses (>1000ms). Normal commands like GetFeatures no longer produce 6 extra debug lines per call. Logging behavior: - Small commands (1-100 packets): only existing call- log, no extras - Large transfers (>100 packets): full progress with send/receive timing - Slow responses (>1s): response duration logged regardless of size - Multi-packet receive: packet count logged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
WebUsbTransportto diagnose firmware update hangs (especially the 99% stuck issue on Windows ARM64)Background
A user on Windows ARM64 (Snapdragon X, build 10.0.26200) experienced firmware update stuck at 99% on a Classic 1S device. Log analysis revealed:
FirmwareUploadsent successfully, buttransferInhung for 31 minutes with zero diagnostic infoonekeyd.exe) failed to start on win-arm64 (Unsupported system: win-arm64), causing 130k+ zombie process log linesfirmwareUpdateV2requests on the same device (errorCode 107: Device interrupted)WakeLockfailed because page was not visible during the updateCurrent transport layer logs only record command names — no timing, no packet counts, no progress during large transfers like
FirmwareUpload.Changes
Logging added to
packages/hd-transport-web-device/src/webusb.ts:connectToDevice()call()send phasecall()send completecall()receive phasereceiveData()release()Expected log output (FirmwareUpload example)
With this, if the 99% hang recurs, we can see exactly whether it's stuck in send or receive, and how long each phase takes.
Test plan
debuglevel and don't pollute production output🤖 Generated with Claude Code