fix(sync): bank each attachment as it arrives, not after the whole batch

[thetechjon]

Jon's vault sync hung on «Syncing…» and then «Sync timed out — check your connection and retry.» (08/09/2026).

Root cause (measured): the vault's Files/ holds 175 images, 83.3 MiB, and the default attachmentsFolder is Files, so every pull classifies all of them as attachmentCreated. syncApply fetched the whole batch (base64 blob API, ~111 MB on the wire) and wrote to IndexedDB only after the batch settled; the 45 s whole-sync watchdog aborted mid-fetch, nothing was banked, and every retry restarted from zero.

Fix: persist each attachment inside the mapper as its blob lands, so a timeout leaves the fetched ones banked and the next pull only sees the rest (converges over a few syncs). getBlobBytes now asks for application/vnd.github.raw (bytes, not base64) with a JSON fallback. SYNC_WATCHDOG_MS and the Files default are untouched (product decisions); the user-side workaround today is the gitignore overlay Files/.

Test: syncApply.test.ts — an AbortError on the 2nd of 3 attachments keeps the 1st persisted and propagates. Fails on the old code ({created: 2, failed: 1} resolved instead of rejected), passes now. Lint, typecheck, 3336 tests, build: green.

Follow-up (separate): thread the watchdog's controller.signal into runApply → getBlobBytes so the abort reaches in-flight blob fetches.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ndqko5Lm9khVfibZdxue5K

[thetechjon]

Second commit pushed: 5f19443 — the gitignore workaround is out, so this makes the sync fit instead of shrinking the work.

What changed. Attachments were applied inside the watchdog-wrapped runSync, so the one part of an apply that scales with vault size gated the parts that don't — notes, conflicts and push all died with it when the 45s watchdog fired. They now stream in behind the sync, reusing the fire-and-forget shape the pull already had for note shells:

• backgroundFill.ts — new fillAttachmentsInBackground() beside fillShellsInBackground. Never rethrows, so a fill can't fail the sync that started it. Resume across reloads needs no new state: syncPull classifies attachments off IDB, so whatever the last fill banked is simply absent from the next pull's attachmentCreated set — the startup auto-pull is the resume.
• useGitHubSync.ts — runApply kicks the fill and returns the queued count instead of awaiting it. Kicked from runApply rather than from each of the four call sites so no path can forget it. One shared backgroundPhase callback replaces two copies of the same inline arrow; it only writes when the status is idle, so the bar reads "Synced" for the notes while the images are still coming down.
• syncApply.ts / github.ts — { signal, onPhase } threaded down into getBlobBytes. Progress reports per banked item as Downloading images… (37 / 175). This also makes commit 1's AbortError branch live: a newer pull aborts the fill in flight instead of racing it for the same paths, and what it already banked stays banked.

SYNC_WATCHDOG_MS and the Files default are untouched.

Push safety — verified by reading syncPush 3b, then asserted. A banked image has localSha === the remote blob sha it came from, so if (plan.remoteSha === plan.localSha) continue skips it: a fill can never cause a re-upload. An image the fill hasn't reached yet is just absent from IDB, and absence is never a delete (only an explicit tombstone is, 3c).

Tests (4 new, all red against the pre-change code for the right reason):

• useGitHubSync.test.ts — resolves to a terminal sync state while the attachment fill is still running (the attachment apply never settles; the sync must still reach ok). The regression itself, at the hook level.
• syncApply.test.ts — an aborted signal stops the batch and keeps what was banked (also asserts the signal reached every getBlobBytes call).
• syncApply.test.ts — reports progress as it banks each image.
• attachmentSyncTimeoutRetry.test.ts — a background-fetched attachment is not re-uploaded, while a genuinely local one still is.

Gate green: lint, typecheck, npm test (262 suites, 3340 passed), build.

One gap that needs your call: with autoSyncOnStart off (default is on), a half-filled attachment set resumes only on the next manual sync, whereas note shells resume on boot unconditionally. Closing it needs either the outstanding classification list persisted, or an unconditional tree fetch on boot for a user who deliberately turned auto-sync off — that's a product decision, so I left it.