nullrouten0andClaude Opus 5.5
618c18d385
Upstream MeshCore, and this fork up to v1.17.1.6 except ESP32 Full builds, rewrote /contacts3 in place, one record after another. A reset or a full volume during that save leaves whole records followed by part of the next one. Upstream reads such a file up to the short read. Here readableContactFile() treats any size that is not a multiple of 152 bytes as unreadable, and since 2311160a9 the bounded recovery then deletes /contacts3. On the first boot after an upgrade, three whole records plus one stray byte became zero contacts. Invariant: on ESP32, RP2040 and STM32, when /contacts3 holds at least one whole record followed by part of one, and /contacts3.bak does not exist, the whole records load and nothing is written or deleted at boot. The next ordinary save publishes only whole records through the existing transaction. Unchanged: whole-record images; a backup still wins over an incomplete primary, including a backup that is unreadable or of unknown presence at boot, which keeps its retry at the recovery boundary; read errors keep the bounded recovery; a file with no whole record is still discarded; nRF52 is not touched. selectContactFile() makes this check only after the strict checks of both names fail, through a new partial_tail mode of readableContactFile(). loadContacts() drops its own size check; its whole-record loop bound already stops before the tail. Add test_companion_contact_partial_tail.py, which runs the real load, recovery and save paths on the uncached ESP32, RP2040 and STM32 harness and on the ESP32 Full cache harness under ASan/UBSan. On the old code all four fail with zero contacts and /contacts3 deleted. It catches 14 of 15 mutations of this change, including a full revert; the other drops a guard whose value is read only when the file handle is valid. Two cases in the uncached storage fixture used a one-byte truncation as their unreadable image; they now use a file shorter than one record, so they still exercise the discard path. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>