pastilhasandClaude Opus 5
4f4e0c5dbc
Bun's recursive fs.watch takes one inotify watch per ENTRY, files included — ~92k for this library against a 65536 ceiling — so the watch could never be established. The ENOSPC came back asynchronously as an FSWatcher 'error' event with no listener, which rethrew and killed the sidecar 17k times, draining the per-UID watch pool for every other process on the machine along the way. Reindexing is triggered instead (the browser button, the phone's pull-to-refresh, the nightly full); an incremental over 6273 folders measures 1.8s. Three index defects the nightly full had been papering over: - outputsExist verified meta.json/cover.jpg/discography.json but neither lyrics/ nor posters/, so a lost lyrics file kept a matching v and a passing check and the album was skipped on every incremental forever — only a full restored it. Record both counts in the manifest and compare them (CACHE_VERSION 2 -> 3). - walk() read a failed readdir as "the folder is gone", and runBuild prunes whatever is missing from next — so one transient EIO on the library disk deleted that folder and its whole subtree from the index. Carry the previous entries forward for every error but ENOENT/ENOTDIR. - a from-scratch build has no previous entries to carry, so it now refuses to publish a slot when any folder was unreadable, leaving the live index alone. A disk that hiccups during the nightly costs a skipped night, not a hole. reindexNow builds in place, so a cache-format upgrade is handed to the staged path rather than rewriting 6k albums underneath live readers. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>