3 Commits

Include renames

Author	SHA1	Message	Date
yonluandClaude Opus 5	3e142f8c35	test(downloads): guard the service fixture on something the fake sets ... `newServiceFixture` stops auto-pick from starting a grab, because none of its tests is about the download and a detached `go m.grab(...)` racing `t.TempDir()`'s cleanup is how they fail. It did that with `MaxSizeMB: 1` -- and the size gates read `Candidate.TotalSize`, which real providers fill and the fake leaves at zero. Zero is under every ceiling, so the guard never fired and the race it was written to prevent kept happening, roughly one run in fifteen: TempDir RemoveAll cleanup: unlinkat ... : directory not empty The guard is a format the fake never produces. Thirty consecutive whole-package runs, none. `TestManualDownloadSatisfiesRequestOnSuccess` was relying on the guard being broken -- it is the one test here that wants the download -- so it now clears the preferences itself rather than depending on a bug. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MeQt5hgXg5YGoNZQ9ozG7L	2026-08-17 22:11:10 -04:00
logan	3d65da0529	test(download): stop racing a download these tests never wanted ... `check` failed on main with two failures in one package, and they are one cause wearing two shapes: service_test.go:66: state = "satisfied", want wanted testing.go:1369: TempDir RemoveAll cleanup: ... directory not empty Every test in service_test.go is about the durable Request that StartDownload leaves behind, and none is about the download. But the fixture is an anchored four-track request with a healthy provider, which is precisely what AutoPickable says yes to -- so Manager.Start fired `go m.grab(...)`, detached and with context.WithoutCancel, and the tests raced it. Measured: the request reaches "satisfied" about 100ms after StartDownload returns, so the first failure is the assertion reading the next state, and the second is that same goroutine still writing into t.TempDir() after the test returned. The fixture now puts the candidate outside the auto-pick size window, so the grab never starts. That is better than waiting for it: with no goroutine there is nothing to be slow, and the tests state what they mean without a timing assumption underneath. A test that does want the download uses managerFixture and sets its own preferences. It passed 20 runs under CPU load, but so did the broken version -- this is a CI-only failure locally, so the cause was proved directly instead: with the fixture's old preferences the request is observably "satisfied" within 100ms of StartDownload, which is what CI read.	2026-08-17 14:16:45 -04:00
yonluandClaude Sonnet 5	65333857e2	refactor(download): rename Want/Request to Request/Download, unify downloads flow, add auto-download guardrails ... The durable "I asked for this" record was called Want, and the one-shot search-and-grab attempt was called Request — names that didn't match what either actually did. Want is now Request, and the old Request/Item is now Download/DownloadItem, with a table-rename migration (download_wants -> download_requests, old download_requests -> download_downloads) safe against both fresh installs and existing data. Every anchored manual download now upserts/reuses a durable Request before running, so a "download now" that finds nothing is picked up by the background reconciler automatically instead of just failing with no trace — the gap that caused this session's repeated "no candidates found" failures on the same album. Also adds auto-download guardrails (file-size min/max with a preferred target, allowed file types) that gate what the pipeline may grab unattended, live-editable from a new settings section. The frontend's wanted-view becomes downloads-view, with a new Downloads tab showing attempt/transfer history that previously had no UI at all. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y2Agd9af5hE7qzti2ackiS	2026-08-10 14:35:57 -04:00