Hardening candidates: v2.31.0

[jeiel85]

Candidates surfaced by what shipped in v2.31.0 — the sidecar metadata mode (#216) and the relative-time localisation. Filed at tag time as a tracker; v2.31.0 ships as it is.

Sidecar mode — cost and scale

• The index is rewritten in full on every note save. writeNoteSidecar reads this device's entries, updates one, and writes the whole file back. On a folder of a thousand notes that is a ~150 KB read plus a ~150 KB write per autosave — once a second while typing — and a sync client watching the folder sees the index change each time. SidecarStore already skips a write whose bytes are unchanged, which only helps when nothing moved. An in-memory dirty set flushed on a coarser trigger would fix it; the honest reason it is not done yet is that the flush points need thinking about, since an unflushed entry is the Search results show same notes multiple times #140 duplicate again. Impact: sync traffic and battery on large folders — the setups this mode is aimed at.
  • Half of this is done in perf(sync): stop re-reading the sidecar index on every note save (#262) #266: this device's own index is now held in memory, so the read is gone and a lost-update window closed with it. The write is unchanged — SidecarStore.write still encodes every entry and replaces the whole file, so the ~150 KB write per autosave and the sync client seeing the index touched each time both stand. The dirty-set flush is what remains.
• Every sidecar write and read lists the whole folder. Both writeNoteSidecar and SidecarStore.readAll call listFiles() on the SAF tree, which is the expensive call in this API. The frontmatter path grew MirrorFileCache for exactly this reason (Hardening candidates: v2.28.2 #222); the sidecar path has no equivalent. Impact: save latency proportional to folder size.
  • Reduced in perf(sync): stop re-reading the sidecar index on every note save (#262) #266, not closed. A save used to list the folder three times and parse every index twice; it now lists once in writeNoteSidecar (plus findFile inside SidecarStore.write, which walks the tree too). The merged view is consulted only for a note this device has not written before. Still proportional to folder size, just with a smaller constant — the MirrorFileCache equivalent does not exist.
• A note deleted on another device leaves its entry in that device's index for ever. Nothing prunes entries whose note is gone, and deleteNote only touches our own. Two devices will each carry the other's stale rows. Harmless today — a stale entry is only consulted by filename, and a missing file matches nothing — but the file grows monotonically. Impact: index size drifts up over a folder's lifetime.

Sidecar mode — correctness edges

• Adoption compares filenames case-insensitively, but a case-sensitive filesystem can hold both. adoptUnclaimedFile and the recorded-name lookup both use equals(ignoreCase = true), which is right for exFAT and a Windows share and wrong for ext4, where Notes.md and notes.md are two files. The frontmatter path made the same choice deliberately (Notes get saved several times #213) and inherits the same edge. Impact: on a Linux-backed sync, a note could adopt the wrong file of a case-differing pair.
• A conflict copy records the remote hash under the original note's entry. That is what stops the copy being taken again every pass — the sidecar equivalent of remoteSeenAt — but it means the entry briefly describes content the local note does not have. Correct, and documented, yet it makes contentHash mean "last wrote or accepted" rather than "last wrote". Worth a second look if anything else ever reads that field. Impact: none observed; a trap for future readers.
• Switching modes is not resumable. SidecarMigration walks the folder rewriting files; a process death halfway leaves some files converted and some not. The import path tolerates that (it strips a stray header and uses its id), so the folder is not corrupt — but the setting has already flipped or not, and nothing reports which files were missed. Impact: a half-converted folder with no way to see it, on a switch over a large folder.

Localisation

• Nothing prevents the next hardcoded string. The relative-time labels were Korean in every locale for as long as they existed, in two separate copies, and were found only because someone went looking for something else. UntranslatedStringTest and ResourceParityTest check that resources exist and agree across locales; neither can see a literal that never became a resource. A lint rule or a source scan for user-facing literals would. Impact: the same defect class recurs silently — this was its third instance after Sync reconcile: conflict copies multiply every pass, and four related mirror defects #217.
  • Done in test: fail the build on user-facing text that never became a resource (#262) #263. HardcodedStringTest scans src/main for the two shapes the defect took: Hangul in any source literal (which is what would have caught formatRelative, whose literals never went near a UI call), and a literal handed straight to Text(), text = or contentDescription =. Both allowlists name real exceptions, and a third test fails once an entry stops matching, so neither list can rot into a blanket exemption.

Release process

• Store notes overran the 500-character Play cap for the third release running. Hardening candidates: v2.26.1 #167, then de/es/fr in v2.30.0, then en-US here. verify-release-notes.ps1 catches it, but only after the files are written, and it warns below 50 characters of headroom — four of six locales are in that band right now. Authoring them against a live count, or shortening the house style for these notes, would stop the rewrite cycle. Impact: an avoidable retry at every cut.
• launch-smoke fails on emulator install often enough to be noise. Three of the last four runs failed with Failure calling service package: Broken pipe or Can't find service: package before the app was ever installed, and passed on a straight re-run. It is deliberately non-required so it does not block a merge, but a check that flakes this often trains people to ignore it. Worth either hardening the install step or dropping the job. Impact: a red check that carries no information.
  • The evidence has moved since this was written (measured 2026-07-24, last 6 android-build runs): launch-smoke passed 4, failed 1, did not run once. Hardening candidates: v2.29.1 #252 already noted two clean runs in a row; this is more of the same, so "three of the last four" no longer describes the job.
  • What replaced it is instrumented-tests, added in test: make the instrumented suite run, and run it in CI (#235, #239) #272 and failing 3 of those same 6 runs. Both jobs are continue-on-error, so the emulator path still gates nothing — but the job worth diagnosing is now the new one. Tracked here rather than in a new issue; the same item appears in Hardening candidates: CI artifact retention and release assets #247 and Hardening candidates: v2.29.1 #252.

[jeiel85]

Audited against the tree at 9969025 as part of a sweep over every open hardening tracker. The body now records what moved, since three items had changed since the tag and none of the boxes showed it.

Done: the hardcoded-string guard (#263).

Partly done, boxes deliberately left open: the two sidecar I/O items. #266 removed the read — this device's index is cached in memory — and cut a save from three folder listings to one. Neither is closed: SidecarStore.write still encodes every entry and replaces the whole file on each autosave, and the remaining listing is still proportional to folder size. The sub-bullets on each item say which half is left.

Unchanged, verified in the tree:

• No prune for entries whose note is gone.
• equals(name, ignoreCase = true) at NoteFolderMirror.kt:180, :184 and :364 — the case-sensitive-filesystem edge is intact.
• The conflict copy still records the remote hash under the original note's entry.
• SidecarMigration still returns Result(converted, skipped, errors) on a clean run and offers nothing for a run that dies halfway.
• Store-note length is still only checkable after the notes are written (same item in Hardening candidates: v2.29.1 #252 and Hardening candidates: v2.30.0 #255).

Evidence replaced: the launch-smoke item was written on "three of the last four runs failed". Re-measured over the last six android-build runs it is 4 passed / 1 failed / 1 not run. The flake moved to instrumented-tests (3 of the same 6 failed), which arrived in #272 with the same continue-on-error treatment. Detail on the item itself.

[jeiel85]

One more item for the "not resumable" family, surfaced by the Codex review on #281 (v2.32.0) rather than by anything in v2.31.0 — it belongs beside the SidecarMigration bullet above rather than in a tracker of its own, since it is the same shape.

• Switching the note-title rule is not resumable either. setNoteTitleSource writes the preference, then NoteRetitler.retitleAll walks the database recomputing title and excerpt. A process death between the two leaves the new rule selected with only part of the list retitled, and nothing retries: the selected option renders as a Button with an empty click handler, so the user has to toggle away and back. Bounded on both sides — the pass writes only the two derived columns (so a partial run is cosmetic, not mixed content), and each note's next save re-derives them under the active rule — and the honest fix, a resume marker plus a startup pass, is more machinery than the failure earns today. Impact: a list showing titles from two rules until the user notices and re-toggles.