Cloud sync: one failed asset transfer aborts the whole run and can crash `hubble cloud watch`

[bholmesdev]

Follow-up from #158, which added `res.ok` checks to asset upload/download in `packages/sync/src/sync.ts`. Throwing there is correct, but no call site catches:

• A single failed asset aborts `sync()` before `writeSyncState`, so all file pushes/pulls from that run go unrecorded and get redone next run.
• In `hubble cloud watch`, sync runs via `void scheduler.enqueue(...)` (`packages/cli/src/index.ts`) with no catch. One transient 500 on an asset fetch becomes an unhandled rejection that kills the watcher process. This crash path predates fix: harden editor and sync edge cases #158 (any backend error hits it), but the new throws make it much more reachable.

Suggested fix:

• Per-asset try/catch in `sync()` that records the failure in `result` and continues.
• Catch inside the CLI scheduler loop so watch mode logs and keeps running.

[github-actions]

Triaged as ready to implement. I confirmed both failure modes against current main.

• Whole-run abort: In packages/sync/src/sync.ts, pushAsset/pullAsset (lines 207-239) are awaited inside serial loops. Any throw propagates out of sync() and skips writeSyncState (line 299), so every file push/pull already accumulated in nextFiles/nextAssets goes unrecorded and is redone next run.
• Watcher crash: createSyncScheduler.run (lines 276-295) only has a finally that resets running — no catch. The void scheduler.enqueue(...) calls in syncContinuously (lines 211 and 235) therefore turn any sync rejection into an unhandled promise rejection that kills the watch process. This path exists on main today, independent of the res.ok checks in fix: harden editor and sync edge cases #158.

Scope is bounded and the implementation area is clear:

• Wrap each asset push/pull in a per-asset try/catch inside sync() that records the failure and continues, so a single bad asset no longer aborts the run before writeSyncState.
• Add a catch inside the scheduler run loop (or at the enqueue call sites) so watch mode logs the error and keeps running.

One small decision for the implementer: the exact shape of the failure record in SyncResult (packages/sync/src/types.ts) — e.g. an assetsFailed count or a list of failed asset paths — and surfacing it in logResult. Note there are currently no tests in packages/sync, so the change likely lands without a package test harness unless one is added.

[github-actions]

Automated Oz implementation has started for #161. Follow along: https://oz.warp.dev/runs/019f51a6-607e-7f1b-a099-ab6f2c74c1bc

[github-actions]

I found the relevant implementation area in packages/sync/src/sync.ts for per-asset transfer handling and packages/cli/src/index.ts for the watch scheduler. I’m implementing the bounded fix there.

[github-actions]

Implemented in draft PR: #162

Summary:

• Asset push/pull failures are now recorded per asset and no longer abort the whole sync before state is written.
• hubble cloud watch now logs scheduler sync errors and keeps running.
• CLI sync output includes failed asset counts and paths.

Validation performed:

• pnpm --filter @hubble.md/sync typecheck
• pnpm --filter @hubble.md/cli build
• pnpm --filter @hubble.md/cli typecheck
• pnpm check
• pnpm build:desktop
• Focused sync verification for failed asset upload plus successful state write.
• Watch-mode verification against an unreachable backend; process stayed alive until external timeout stopped it.

Note: in this sandbox, pnpm was run through Corepack with a temporary PATH shim because no pnpm executable name was initially installed.