Obsidian's mobile storage layer forwards mtime/ctime to Capacitor's
Filesystem.setTimes, whose native binding casts the value to a Java Long.
A non-integer (float) timestamp makes that cast throw (ClassCastException:
Double cannot be cast to Long), which crashes the app on launch as soon as
such a document is replicated in.
Float timestamps can reach the database from any client that stores
fs.Stats.mtimeMs without flooring. Coerce mtime/ctime to integer ms at the
Obsidian vault and storage adapter write boundary, so a float already
present in the mesh can't crash the app regardless of where it came from.
The truly central choke point is dbToStorage in livesync-commonlib; a
matching guard there would cover the CLI and webapp too. This change
protects the platform that actually crashes.
Claude-Session: https://claude.ai/code/session_0123E9jVQrsgu3zb82Csuwhi
CLIWatchAdapter._toNodeFile passed chokidar's raw stats.ctimeMs/mtimeMs
straight through. On Linux those carry sub-millisecond precision (e.g.
1778511180024.462), so watch-mode file changes wrote non-integer
timestamps into the database.
The earlier floor fix (3f7bb047) covered the scan/stat adapters but missed
this watch path, which is the one the daemon actually uses at runtime.
Mobile clients then crash on such a document because Capacitor's
Filesystem.setTimes casts the value to a Java Long (ClassCastException:
Double cannot be cast to Long).
Floor ctimeMs/mtimeMs here, with a null guard so a partial stat still
falls back to Date.now(). Adds a regression test that a fractional stat is
floored.
Claude-Session: https://claude.ai/code/session_0123E9jVQrsgu3zb82Csuwhi
Reason:
- The non-bulk notice regression test should exercise the real resolve-by-newest call path.
Changes:
- Resolve a mocked conflict through `_anyResolveConflictByNewest` and assert that its success notice remains visible.
Reason:
- Bulk newest resolution should not display one success notice per file, while non-bulk resolution must retain its existing notice.
Changes:
- Pass an explicit notice flag only through the bulk resolution path.
- Cover bulk suppression, non-bulk notices, and ten-file progress updates.
Bulk newest-revision conflict resolution created one notice per resolved file
and updated progress for nine out of every ten files.
Keep per-file bulk resolution success messages in the log without displaying
notices, update notice-level progress once every ten files, and cover both
behaviours with unit tests.
Consume commonlib's delivery lifecycle, classify finite replication entry points, and document why the five-minute inactivity fuse is only a leak safety valve. Record the remote-activity counter correction and preserve continuous replication's unbounded live channel.
vorotamoroz