naturalise foreign entry ids at the import seam instead of trusting them (v2.14.85) A Peach entry id is a UUID, but a restored or imported file carries whatever id its author used and no reader on either platform bounds it. One restored entry with an oversized id would ride into every future sync frame and be rejected there — a permanent, opaque failure on both platforms, caused by data that was already local. addEntry, addEntries and replaceEntries now replace an id that is not 1-64 chars of [A-Za-z0-9_-] with a freshly minted UUID. These three are the only entry-write choke points and they cover every foreign path: PeachScript paste, .peach files, CSV and vendor exports all funnel through ImportScreen into addEntries/replaceEntries. Restore-from-our-own-backup paths never needed this because their ids are already Peach ids. The action is mint, not reject, because this is the last point where an id is still local: the worst outcome is one duplicate if the same vault is later restored beside a device still holding the old id, which is visible and fixable, whereas rejecting would lose the user's import. Sync deliberately does not normalize. applyMergedRemoteEntries adopts a peer's id verbatim — that is the only thing keeping two devices agreed on which entry they are discussing — and a test asserts a 124-char peer id survives untouched so the seam cannot drift into the sync path later. Verification: four new cases — a UUID and a 22-char vendor id kept, an oversized and an injection-shaped id minted as UUIDs with the entries intact, and the sync path adopting a long peer id verbatim; full JVM suite 1043 tests / 0 failures / 0 errors / 2 skipped, up from 1040; lintDebug 0 errors and 90 warnings, unchanged; assembleDebug and debug androidTest sources compile.

dev · 1 week ago · 2026-09-01 · 6.7 MB

session: define the entry-id namespace at the import seam · agent: hy4-preview

$ koh steal kepr.uk/peach-android@cba84286c56f
·
← cb96cb04dbc9 1f30816e897e →
⇓ download .face