Download-albums example test no longer depends on the disk's free space (closes #160) #161

Merged
clawbot merged 1 commits from issue-160-download-albums-free-space into next 2026-10-03 15:30:54 +02:00
Collaborator

Fixes #160.

The download-albums example test opened its libraries with freeBelowBytes at its 50 GiB default. On a disk with under 50 GiB free, the content cache's limit on originals drops to zero. Then downloading any other photo evicts photo 1's cached original, and photo.download() fetches it again instead of copying it, so the count is 4 instead of 3. Both of the test's libraries now open with freeBelowBytes: 0. The 50 GiB default in src/ is unchanged, and nothing under src/ changed.

What the diff does not show: a download straight to a save path also runs the cache's eviction step. So any test that caches one original and then downloads another can lose the first one on a small disk. I read every other test that opens a library or content cache with the real free space (content.test.ts, content-library.test.ts, precache.test.ts, the backup, metadata-backup, thumbnails and command tests). None of their results depend on it. Each one serves a single file, reads each original as soon as it is fetched, caches only a file the backup handles before downloading anything else, or counts only thumbnail fetches. The eviction tests that pass their own statfs are left alone.

TODO.md gets the Completed Steps entry.

Model: opus-5-5

Fixes https://git.eeqj.de/sneak/quak/issues/160. The download-albums example test opened its libraries with `freeBelowBytes` at its 50 GiB default. On a disk with under 50 GiB free, the content cache's limit on originals drops to zero. Then downloading any other photo evicts photo 1's cached original, and `photo.download()` fetches it again instead of copying it, so the count is 4 instead of 3. Both of the test's libraries now open with `freeBelowBytes: 0`. The 50 GiB default in `src/` is unchanged, and nothing under `src/` changed. What the diff does not show: a download straight to a save path also runs the cache's eviction step. So any test that caches one original and then downloads another can lose the first one on a small disk. I read every other test that opens a library or content cache with the real free space (`content.test.ts`, `content-library.test.ts`, `precache.test.ts`, the backup, metadata-backup, thumbnails and command tests). None of their results depend on it. Each one serves a single file, reads each original as soon as it is fetched, caches only a file the backup handles before downloading anything else, or counts only thumbnail fetches. The eviction tests that pass their own `statfs` are left alone. `TODO.md` gets the Completed Steps entry. Model: opus-5-5
clawbot added 1 commit 2026-10-03 14:46:58 +02:00
The test left freeBelowBytes at its 50 GiB default, so on a disk with under
50 GiB free the content cache's limit fell to zero. Downloading another photo
then evicted photo 1's cached original, and the test fetched it a fourth time
instead of copying it. Both of its libraries now open with freeBelowBytes: 0.
Every other test that opens a library or content cache with the real free
space was read; none has a result that depends on it. The 50 GiB default is
unchanged.

Model: opus-5-5
clawbot added the needs-review label 2026-10-03 14:47:00 +02:00
clawbot self-assigned this 2026-10-03 14:47:01 +02:00
Author
Collaborator

Review passed.

Model: opus-5-5

Review passed. Model: opus-5-5
clawbot merged commit 14ac7d05ef into next 2026-10-03 15:30:54 +02:00
clawbot deleted branch issue-160-download-albums-free-space 2026-10-03 15:30:54 +02:00
Sign in to join this conversation.