Fix device configuration streaming and Settings lifecycle - #1325
Conversation
|
@RCGV1 is attempting to deploy a commit to the Meshtastic Team on Vercel. A member of the Team first needs to authorize it. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
🚧 Files skipped from review as they are similar to previous changes (3)
📝 WalkthroughWalkthroughThe changes add LoRa configuration defaults, make configuration waiting resolve from device-store updates, remount settings forms after resets, improve editor dirty-state handling, and replace the SDK configuration handshake with a nonce-validated two-stage flow using unacknowledged packet sends. ChangesWeb configuration behavior
SDK configuration handshake
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant MeshClient
participant Queue
participant Firmware
MeshClient->>Queue: Send heartbeat and config-stage request
Queue->>Firmware: Transmit without routing acknowledgement
Firmware-->>MeshClient: Return config completion nonce
MeshClient->>Queue: Send nodes-stage request
Queue->>Firmware: Transmit without routing acknowledgement
Firmware-->>MeshClient: Return nodes completion nonce
MeshClient->>MeshClient: Dispatch completion and mark configured
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
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 |
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/web/src/core/hooks/useWaitForConfig.ts`:
- Around line 24-42: Update the suspended waiter in useWaitForConfig so each
store subscription is disposed when the waiting component unmounts or the
suspended render is abandoned, while still resolving and unsubscribing when
hasRequestedConfig returns true. Ensure repeated pending renders do not leave
accumulated listeners on useDeviceStore.
In `@packages/sdk/src/core/client/MeshClient.progress.test.ts`:
- Around line 113-120: Update the test around client.configure and the
config-complete responses to await completion through handleConfigComplete or
the completed collection instead of using the fixed 20 ms timeout. Ensure both
config-complete packets are processed before asserting sent,
progress.value.phase, and completed, while preserving the expected ignored-nonce
results.
In `@packages/sdk/src/core/client/MeshClient.ts`:
- Around line 158-164: Update the connect() documentation and completion
behavior to reflect that it resolves after configure() writes only the config
request; the nodes-only request is sent later by handleConfigComplete(). Remove
the inaccurate “both requests” contract while preserving the existing
DeviceConnecting status update and configure() flow.
In `@packages/sdk/src/core/queue/Queue.ts`:
- Around line 113-120: Update the wait loop in the queue send flow around
queuedItem and processQueue so it also detects when complete() has cleared the
queued control packet. Reject the pending configure() or heartbeat() operation
when the detached item is removed, instead of continuing to poll queuedItem.sent
forever; preserve the existing success path and cleanup for packets that are
sent normally.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 540b024a-e082-4e7e-8717-aac204e75997
📒 Files selected for processing (12)
apps/web/src/components/PageComponents/Settings/LoRa.tsxapps/web/src/core/hooks/useWaitForConfig.test.tsxapps/web/src/core/hooks/useWaitForConfig.tsapps/web/src/pages/Settings/index.tsxapps/web/src/validation/config/lora.test.tsapps/web/src/validation/config/lora.tspackages/sdk/src/core/client/MeshClient.progress.test.tspackages/sdk/src/core/client/MeshClient.tspackages/sdk/src/core/packet-codec/decodePacket.tspackages/sdk/src/core/queue/Queue.tspackages/sdk/src/features/config/ConfigEditor.test.tspackages/sdk/src/features/config/domain/ConfigEditor.ts
Summary
serialHalOnlyform value, correctly reset controlled forms, and ignore protobuf metadata when calculating dirty state.Root cause
The web client treated local configuration requests like acknowledged mesh packets and used one completion path for multiple streaming modes. Settings also suspended on a promise that could never resolve. Separately, form values omitted by older firmware and protobuf metadata caused invalid boolean and false-dirty states.
Impact
HTTP and serial clients can complete configuration streaming consistently, Settings loads after the requested section arrives, and
Serial HAL Onlybehaves as a boolean with a clean edit/reset lifecycle.Validation
NODE_OPTIONS=--no-experimental-webstorage pnpm vitest run: 70 files, 393 tests passed.pnpm --filter meshtastic-web build: passed.pnpm lint: passed with existing warnings.git diff --check: passed.E2E (real device): passed in 2m8s.Serial HAL Onlychangedfalse → true → Reset → false; Save returned disabled, dirty state cleared, and no boolean validation error appeared. No configuration was written to the device.Notes
Summary by CodeRabbit
serialHalOnlydefault when omitted.