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 @coderabbitai help to get the list of available commands and usage tips.}

@coderabbitai is the NVS blob write solid with commit 3f7e648

#!/bin/bash
# Read the nvs-editor.js file to inspect the blob upload implementation
fd -e js nvs-editor | head -5
cat js/nvs-editor.js

@Jason2866 After reading the full _uploadBlobToNVS implementation carefully, the core logic is solid for all typical cases. Here is a detailed breakdown:

✅ What's correct

⚠️ Two edge cases worth knowing about

1. Empty file upload (0 bytes)
If a user uploads a 0-byte file, all data chunks get deleted via _deleteEntry, and the blob_index is left with totalSize=0, chunkCount=0. This is a valid degenerate state but creates an orphan index entry with no data — the NVS library on the ESP32 might not handle that gracefully. A simple guard would prevent it:

if (fileBytes.length === 0) {
  throw new Error("Cannot upload an empty file as blob replacement.");
}

2. span=1 blob_data entries (theoretical)
If a parsed blob_data entry somehow has span=1, maxSize would be 0, writeLen would be 0, and the entry would get deleted rather than written. However, this cannot occur in valid NVS — a blob_data entry always requires span ≥ 2 (1 header + at least 1 data slot). So in practice this path is unreachable.

Summary

The NVS blob write in commit 3f7e648 is solid for all real-world use: same-or-smaller file replacements across single or multi-chunk blobs, correct CRC chain throughout, and clean cleanup of unused trailing slots. The only practical hardening worth adding is a guard against 0-byte file uploads.