Fix pairing recovery and harden device, runtime, and backup reliability - #2
Fix pairing recovery and harden device, runtime, and backup reliability#2bcbetterninja wants to merge 3 commits into
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 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.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6cc6b2403b
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| }); | ||
|
|
||
| const wss = new WebSocketServer({ noServer: true }); | ||
| const wss = new WebSocketServer({ noServer: true, maxPayload: 1024 * 1024 }); |
There was a problem hiding this comment.
Preserve the supported camera proxy payload size
Raising an incoming camera-proxy-response with a moderately large snapshot now closes the kiosk socket before the response handler can run: the client explicitly accepts camera bodies up to 10 MiB in client/src/platform/linux/ws_client.rs:805-822 and base64-encodes them into the WebSocket message, while this limit rejects messages above 1 MiB (roughly 768 KiB of raw image data). High-resolution camera snapshots therefore cause the pending admin request to fail and /api/admin/cameras/:id/proxy to return 502; either align maxPayload with the existing 10 MiB contract plus base64 overhead or introduce a smaller/streamed camera response contract.
Useful? React with 👍 / 👎.
Pairing could stop permanently after a network/JSON error, lose a confirmed device's identity on its first bundle failure, or strand ioBOX credentials when the one-time claim response was lost. This change makes enrollment retryable across disconnects and restarts and fixes the related server, runtime and deployment defects found in the repository review.
Changes
Validation
4d943ae(Actions run 34753594964). Physical device/media/TPM and power-loss qualification remains necessary.Rollout requirements
Read
docs/pairing-recovery.md,docs/backup-recovery.mdandiobox-firmware/README.mdbefore deployment. Deploy server and Node-RED components together, then clients. Configure verified publicBF_IOBOX_TLS_CA_PEMandBF_IOBOX_OTA_PUBLIC_KEY_PEMrepository variables before release builds; absent trust anchors intentionally fail the release build. PR test trust is not deployable.Back up and inspect the actual existing PostgreSQL cluster before changing its volume mount. Legacy stranded ioBOX credentials require operator reset/re-enrollment; serial-only retrieval is unsafe. New enrollment secrets authenticate retries but do not prove factory identity. Managed-image/polkit changes require the updated image or installation steps, not only a binary update.