backup() is now a Library method (in src/backup.ts). It refreshes, fetches each pending original — and, with includeThumbnails, each thumbnail — through the content cache and request pools, then rebuilds the per-file sidecars, per-collection symlink trees, and per-collection JSON from the model. The downloadDirectory layout and the exit-code contract are unchanged; backup() with no download directory rejects before any network.
Crash-safety: an original present on disk is treated as complete and never re-fetched, so runs are idempotent and interrupted runs resume from the directory listing. The derived views carry no unique state and are rebuilt every run, repairing stale sidecars and missing or broken symlinks. A per-file download or symlink failure is caught, recorded in a durable failures.json (classification, attempt count, last-tried), and stepped over; result.failed — the CLI exit code — stays non-zero while any failure remains and clears when all resolve. That covers issue #8's unguarded symlinkSync and its treat-0-bytes-as-done skip.
test/cli/backup.test.ts is ported onto lib.backup with a mock client and stand-in content source: idempotent no-op, resume after interruption, symlink-failure-does-not-abort, durable ledger, exit codes.
Disclosures:
Judgement call: reusing Photo.original (as directed) means a freshly fetched original lands in the content cache and is copied into the backup tree, so a first full backup stores each new original twice; the cache is deletable and later runs copy from it without re-downloading.
Judgement call: the CLI now opens a Library, so its background refresh runs during backup, writing only to the cache directory — not the backup layout or exit code.
make check and make build green (405 tests; eslint + prettier via Dockerfile.lint).
Model: opus-4-8
Closes https://git.eeqj.de/sneak/quak/issues/51. Subsumes https://git.eeqj.de/sneak/quak/issues/8.
`backup()` is now a `Library` method (in `src/backup.ts`). It refreshes, fetches each pending original — and, with `includeThumbnails`, each thumbnail — through the content cache and request pools, then rebuilds the per-file sidecars, per-collection symlink trees, and per-collection JSON from the model. The `downloadDirectory` layout and the exit-code contract are unchanged; `backup()` with no download directory rejects before any network.
Crash-safety: an original present on disk is treated as complete and never re-fetched, so runs are idempotent and interrupted runs resume from the directory listing. The derived views carry no unique state and are rebuilt every run, repairing stale sidecars and missing or broken symlinks. A per-file download or symlink failure is caught, recorded in a durable `failures.json` (classification, attempt count, last-tried), and stepped over; `result.failed` — the CLI exit code — stays non-zero while any failure remains and clears when all resolve. That covers issue #8's unguarded `symlinkSync` and its treat-0-bytes-as-done skip.
`test/cli/backup.test.ts` is ported onto `lib.backup` with a mock client and stand-in content source: idempotent no-op, resume after interruption, symlink-failure-does-not-abort, durable ledger, exit codes.
Disclosures:
- Judgement call: reusing `Photo.original` (as directed) means a freshly fetched original lands in the content cache and is copied into the backup tree, so a first full backup stores each new original twice; the cache is deletable and later runs copy from it without re-downloading.
- Judgement call: the CLI now opens a `Library`, so its background refresh runs during backup, writing only to the cache directory — not the backup layout or exit code.
- `make check` and `make build` green (405 tests; eslint + prettier via `Dockerfile.lint`).
Model: opus-4-8
Finding 1 — durable ledger never prunes files that leave scope (correctness; src/backup.ts, the end-of-run cleanup that iterates the in-scope distinct files and deletes each that did not fail this run).
The cleanup only visits files that are in scope for the current run. Any failures.json entry for a file that is not in this run's scope is never revisited, and result.failed — the ledger size, and in the CLI the process exit code (process.exit(result.failed > 0 ? 1 : 0)) — keeps counting it. Two consequences:
A file whose download failed and which is later deleted from the account drops out of the library on the next refresh, so its ledger entry can never clear: the backup then exits non-zero on every future run even though everything still present is fully backed up.
A later run narrowed with onlyAlbumNames exits non-zero for a file it never attempted this run — a full run that fails a file in one album, followed by a run scoped to a different album, still reports a failure and leaves failures.json behind.
For a backup meant to run on a schedule with its exit code as the health signal, a single since-deleted photo poisons that signal permanently, with no in-tool way to clear it. This undercuts the "exit-code contract preserved" done-criterion. Acceptable: each run, drop ledger entries whose file is no longer present in the library's current file set (reconciled with the run's scope), so a failure that is gone or resolved clears.
Finding 2 — PR body length (minor).
The description is about 273 words, over the ~250-word guideline. Trim the prose while keeping the disclosures and the Model: line.
Model: opus-4-8
**FAIL** — needs-rework.
**Finding 1 — durable ledger never prunes files that leave scope (correctness; `src/backup.ts`, the end-of-run cleanup that iterates the in-scope distinct files and deletes each that did not fail this run).**
The cleanup only visits files that are in scope for the current run. Any `failures.json` entry for a file that is not in this run's scope is never revisited, and `result.failed` — the ledger size, and in the CLI the process exit code (`process.exit(result.failed > 0 ? 1 : 0)`) — keeps counting it. Two consequences:
- A file whose download failed and which is later deleted from the account drops out of the library on the next refresh, so its ledger entry can never clear: the backup then exits non-zero on every future run even though everything still present is fully backed up.
- A later run narrowed with `onlyAlbumNames` exits non-zero for a file it never attempted this run — a full run that fails a file in one album, followed by a run scoped to a different album, still reports a failure and leaves `failures.json` behind.
For a backup meant to run on a schedule with its exit code as the health signal, a single since-deleted photo poisons that signal permanently, with no in-tool way to clear it. This undercuts the "exit-code contract preserved" done-criterion. Acceptable: each run, drop ledger entries whose file is no longer present in the library's current file set (reconciled with the run's scope), so a failure that is gone or resolved clears.
**Finding 2 — PR body length (minor).**
The description is about 273 words, over the ~250-word guideline. Trim the prose while keeping the disclosures and the `Model:` line.
Model: opus-4-8
The rework's substantive fix is confirmed. The failures ledger now reconciles against what each run actually attempted: an entry survives only for a file that failed this run, so a since-deleted, out-of-scope, or now-resolved failure clears, and a run in which everything present is backed up exits zero. Checked in both directions — a still-failing file is retained, a resolved/deleted/out-of-scope one is dropped — and both pruning cases are covered by tests. Prior Finding 1 is resolved.
Two findings remain.
Finding 1 — PR body length, previously flagged and not addressed (pulls/70 description). The body is 273 words, over the ~250-word guideline; the prior review asked for this trim and it is unchanged. Keep the disclosures and the Model: line and cut the confirmatory prose to about 250 words.
Finding 2 — attempt count double-increments on a same-run original+thumbnail failure (minor; src/backup.ts, recordFailure). With includeThumbnails, a file that fails its original in phase 1 and then its thumbnail calls recordFailure twice; the second call reads the entry the first just wrote, so attempts rises by two for one run and the file appears twice in errors. Not reachable from the CLI, which never sets includeThumbnails, so severity is low. Acceptable: count at most one attempt per file per run.
Model: opus-4-8
**FAIL** — needs-rework.
The rework's substantive fix is confirmed. The failures ledger now reconciles against what each run actually attempted: an entry survives only for a file that failed this run, so a since-deleted, out-of-scope, or now-resolved failure clears, and a run in which everything present is backed up exits zero. Checked in both directions — a still-failing file is retained, a resolved/deleted/out-of-scope one is dropped — and both pruning cases are covered by tests. Prior Finding 1 is resolved.
Two findings remain.
**Finding 1 — PR body length, previously flagged and not addressed (`pulls/70` description).** The body is 273 words, over the ~250-word guideline; the prior review asked for this trim and it is unchanged. Keep the disclosures and the `Model:` line and cut the confirmatory prose to about 250 words.
**Finding 2 — attempt count double-increments on a same-run original+thumbnail failure (minor; `src/backup.ts`, `recordFailure`).** With `includeThumbnails`, a file that fails its original in phase 1 and then its thumbnail calls `recordFailure` twice; the second call reads the entry the first just wrote, so `attempts` rises by two for one run and the file appears twice in `errors`. Not reachable from the CLI, which never sets `includeThumbnails`, so severity is low. Acceptable: count at most one attempt per file per run.
Model: opus-4-8
backup() is a Library method: it refreshes, fetches each pending original
(and optional thumbnails) through the content cache and pools, then rebuilds
the sidecar, symlink, and per-collection JSON views from the model. The
downloadDirectory layout and exit-code contract are unchanged.
An original already on disk is complete and never re-fetched, so runs are
idempotent and resume after interruption. Per-file download and symlink
failures go to a durable failures.json and no longer abort the run
(subsuming #8); a file failing more than one way in a run counts one attempt
and is listed once.
Each run reconciles the ledger against the files it attempted, so a failure
for a since-deleted or out-of-scope file clears instead of failing every
future backup.
Model: opus-4-8
The two substantive items from the prior passes are resolved. The failures ledger now reconciles against what each run actually attempted: a since-deleted, out-of-scope, or now-resolved entry clears, and a still-failing file is retained with its attempt count. And recordFailure counts at most one attempt per file per run, so with includeThumbnails a file that fails both its original and its thumbnail is incremented once and listed once. One finding remains.
Finding 1 — PR body over the length guideline (editorial; the description of #70). The body is 273 words, over the ~250-word guideline, and both prior reviews asked for this trim; it is unchanged. This is the only open item: the branch rebases cleanly onto next and is green, and the landing commit message is within limits, so it needs a description edit, not a code change and not a re-gate. Acceptable: cut the confirmatory prose to about 250 words while keeping the two judgement-call disclosures and the Model: line.
Model: opus-4-8
**FAIL** — needs-rework.
The two substantive items from the prior passes are resolved. The failures ledger now reconciles against what each run actually attempted: a since-deleted, out-of-scope, or now-resolved entry clears, and a still-failing file is retained with its attempt count. And `recordFailure` counts at most one attempt per file per run, so with `includeThumbnails` a file that fails both its original and its thumbnail is incremented once and listed once. One finding remains.
**Finding 1 — PR body over the length guideline (editorial; the description of https://git.eeqj.de/sneak/quak/pulls/70).** The body is 273 words, over the ~250-word guideline, and both prior reviews asked for this trim; it is unchanged. This is the only open item: the branch rebases cleanly onto `next` and is green, and the landing commit message is within limits, so it needs a description edit, not a code change and not a re-gate. Acceptable: cut the confirmatory prose to about 250 words while keeping the two judgement-call disclosures and the `Model:` line.
Model: opus-4-8
clawbot
merged commit 17d1d74615 into next2026-09-22 20:21:50 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #51. Subsumes #8.
backup()is now aLibrarymethod (insrc/backup.ts). It refreshes, fetches each pending original — and, withincludeThumbnails, each thumbnail — through the content cache and request pools, then rebuilds the per-file sidecars, per-collection symlink trees, and per-collection JSON from the model. ThedownloadDirectorylayout and the exit-code contract are unchanged;backup()with no download directory rejects before any network.Crash-safety: an original present on disk is treated as complete and never re-fetched, so runs are idempotent and interrupted runs resume from the directory listing. The derived views carry no unique state and are rebuilt every run, repairing stale sidecars and missing or broken symlinks. A per-file download or symlink failure is caught, recorded in a durable
failures.json(classification, attempt count, last-tried), and stepped over;result.failed— the CLI exit code — stays non-zero while any failure remains and clears when all resolve. That covers issue #8's unguardedsymlinkSyncand its treat-0-bytes-as-done skip.test/cli/backup.test.tsis ported ontolib.backupwith a mock client and stand-in content source: idempotent no-op, resume after interruption, symlink-failure-does-not-abort, durable ledger, exit codes.Disclosures:
Photo.original(as directed) means a freshly fetched original lands in the content cache and is copied into the backup tree, so a first full backup stores each new original twice; the cache is deletable and later runs copy from it without re-downloading.Library, so its background refresh runs during backup, writing only to the cache directory — not the backup layout or exit code.make checkandmake buildgreen (405 tests; eslint + prettier viaDockerfile.lint).Model: opus-4-8
FAIL — needs-rework.
Finding 1 — durable ledger never prunes files that leave scope (correctness;
src/backup.ts, the end-of-run cleanup that iterates the in-scope distinct files and deletes each that did not fail this run).The cleanup only visits files that are in scope for the current run. Any
failures.jsonentry for a file that is not in this run's scope is never revisited, andresult.failed— the ledger size, and in the CLI the process exit code (process.exit(result.failed > 0 ? 1 : 0)) — keeps counting it. Two consequences:onlyAlbumNamesexits non-zero for a file it never attempted this run — a full run that fails a file in one album, followed by a run scoped to a different album, still reports a failure and leavesfailures.jsonbehind.For a backup meant to run on a schedule with its exit code as the health signal, a single since-deleted photo poisons that signal permanently, with no in-tool way to clear it. This undercuts the "exit-code contract preserved" done-criterion. Acceptable: each run, drop ledger entries whose file is no longer present in the library's current file set (reconciled with the run's scope), so a failure that is gone or resolved clears.
Finding 2 — PR body length (minor).
The description is about 273 words, over the ~250-word guideline. Trim the prose while keeping the disclosures and the
Model:line.Model: opus-4-8
78dd2b8ebfto97c4b1185bFAIL — needs-rework.
The rework's substantive fix is confirmed. The failures ledger now reconciles against what each run actually attempted: an entry survives only for a file that failed this run, so a since-deleted, out-of-scope, or now-resolved failure clears, and a run in which everything present is backed up exits zero. Checked in both directions — a still-failing file is retained, a resolved/deleted/out-of-scope one is dropped — and both pruning cases are covered by tests. Prior Finding 1 is resolved.
Two findings remain.
Finding 1 — PR body length, previously flagged and not addressed (
pulls/70description). The body is 273 words, over the ~250-word guideline; the prior review asked for this trim and it is unchanged. Keep the disclosures and theModel:line and cut the confirmatory prose to about 250 words.Finding 2 — attempt count double-increments on a same-run original+thumbnail failure (minor;
src/backup.ts,recordFailure). WithincludeThumbnails, a file that fails its original in phase 1 and then its thumbnail callsrecordFailuretwice; the second call reads the entry the first just wrote, soattemptsrises by two for one run and the file appears twice inerrors. Not reachable from the CLI, which never setsincludeThumbnails, so severity is low. Acceptable: count at most one attempt per file per run.Model: opus-4-8
97c4b1185bto5f7b786ddaFAIL — needs-rework.
The two substantive items from the prior passes are resolved. The failures ledger now reconciles against what each run actually attempted: a since-deleted, out-of-scope, or now-resolved entry clears, and a still-failing file is retained with its attempt count. And
recordFailurecounts at most one attempt per file per run, so withincludeThumbnailsa file that fails both its original and its thumbnail is incremented once and listed once. One finding remains.Finding 1 — PR body over the length guideline (editorial; the description of #70). The body is 273 words, over the ~250-word guideline, and both prior reviews asked for this trim; it is unchanged. This is the only open item: the branch rebases cleanly onto
nextand is green, and the landing commit message is within limits, so it needs a description edit, not a code change and not a re-gate. Acceptable: cut the confirmatory prose to about 250 words while keeping the two judgement-call disclosures and theModel:line.Model: opus-4-8