v8.16.1

Summary

Post-release, support tickets reported apps using syncthing exiting on their own with ExitCode 137 (OOMKilled: false) and never restarting. Root cause confirmed on two production nodes: a false positive in the phantom_index_empty_disk mount-safety guard.

An app whose synced payload is only empty directories has globalBytes > 0 in syncthing's index (it counts directory entries) while the disk holds no regular file. checkDirectoryHasSyncScopedContent walked files only, read that as "index claims data but disk is empty", and verifySendReceiveFolderSafety flagged phantom_index_empty_disk. The reconciler then stopped the container (appDockerStop → SIGKILL/137) and, because re-promotion is gated behind the same check, held it down indefinitely — a healthy, fully-synced app that never came back.

Log evidence (two nodes): folder 100.00% synced (256/256 bytes), a connected peer at 256 bytes, mounted=true — yet declared a stale/phantom index. The 256 bytes were confirmed on-disk to be empty synced directories.

Fix

Make the disk-side check like-for-like with the index it is compared against:

• countFilesUpTo gains a countDirs option — a non-excluded directory counts as content in its own right, not only as a subtree to descend into.
• checkDirectoryHasSyncScopedContent counts directories and also excludes the .stfolder marker (alongside .stignore and the ignored backup/).

Data-loss protection preserved: a genuinely wiped disk keeps only housekeeping (.stfolder/.stignore/backup), all excluded, so it still reads empty and the phantom guard still fires.

Tests

tests/unit/syncthingFolderStateMachine.test.js — new cases:

• an empty-directory folder is safe (the false positive);
• a wiped disk with only housekeeping still flags phantom (protection intact).

All 68 state-machine tests pass, plus syncthingMonitor (15) and syncthingMonitorHelpers (38).

Version

8.16.0 → 8.16.1 (patch).

🤖 Generated with Claude Code