Skip node DB fetch during --ota-update / --reboot-ota - #961
Conversation
OTA only needs the local node to send the startOTA admin request and then streams firmware directly to the loader over WiFi; it never reads the node DB. On a device with a large node DB the initial dump can stall and the firmware closes the API connection before it processes the OTA request, so OTA silently fails. Imply --no-nodes for --ota-update / --reboot-ota. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughOTA update and OTA reboot actions now disable node database fetching before the related administrative request. ChangesOTA request preparation
Estimated code review effort: 1 (Trivial) | ~5 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #961 +/- ##
==========================================
- Coverage 67.45% 67.44% -0.01%
==========================================
Files 25 25
Lines 4762 4764 +2
==========================================
+ Hits 3212 3213 +1
- Misses 1550 1551 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Problem
meshtastic --host <ip> --ota-update firmware.bincan silently fail to start the OTA on devices with a large node DB. The device never enters OTA mode (the WiFi OTA loader on:3232never comes up) and the client ends withConnection refused.Root cause
The OTA flow only needs the local node — to send the
startOTAadmin request — and then streams the firmware directly to the OTA loader over WiFi. It never reads the node DB. But the CLI still fetches the full node DB on connect.On a device with a large node DB (e.g. ~250 nodes on an ESP32-S3 in a busy public mesh), that dump stalls and the firmware closes the API connection before it processes the OTA request:
So
startOTAis never handled, the device doesn't reboot into the OTA loader, and--ota-updatefails. Passing--no-nodesmanually works around it.Fix
Imply
--no-nodeswhen--ota-updateor--reboot-otais used, since neither reads the node DB. No effect on other commands.Verification
On a T-Beam 1W (ESP32-S3, ~250-node DB) with the unified WiFi OTA loader installed:
meshtastic --host <ip> --ota-update fw.bin→Connection refused; device log showsTCP client write short (0/61 bytes), closing API serviceand noOTA Requested.--no-nodesneeded):meshtastic --host <ip> --ota-update fw.bin→OTA update completed successfully!; device log showsOTA Requested → OTA partition contains combined BLE/WiFi OTA Loader → Rebooting to WiFi OTA → Listening on TCP port 3232.🤖 Generated with Claude Code
Summary by CodeRabbit