v1.1.0-beta.069 - fix: use the accurate per-issue release year when searching (long-running N+1)
📅 The issue-year override never reached the actual search
- The engine overrides a series' year with the specifically-requested issue's release year so a long-running series finds the right post (issue #22 of a 2024 series that shipped in 2026 lives at "wolverine-22-2026", not "...2024"). The log even said "Overriding series year (2024) with accurate issue release year (2026)" — then generated "Wolverine 22 2024" and searched/filtered under 2024 anyway, finding nothing. Two compounding bugs:
- generateSearchQueries was handed the SERIES year, not the overridden dynamicYear — so every query string embedded 2024.
- The year FILTER misfired too: activeYear = isPackQuery ? year : dynamicYear, where isPackQuery looked for a '#'/'issue' marker. But the query builder strips the '#', so a plain "Wolverine 22" was misclassified as a pack query and fell back to the series year. This left dynamicYear effectively dead for normal issue requests — fixing only the query string wouldn't help, because the filter still rejected the 2026 post (|2026-2024| > 1).
🔧 Fix (src/lib/automation.ts)
- Build queries from dynamicYear (== year unless overridden), so they carry the accurate issue year ("Wolverine 22 2026").
- Replaced the brittle '#'-marker isPackQuery regex with queryTargetsIssue(query): a query targets a specific issue when it carries any bare non-year digit. True series/pack queries ("Wolverine", "Wolverine collection") have none and correctly keep the series year, so a "(2024)" collection isn't rejected for a 2026 issue.
- Also explains the earlier "year mismatch (2024 vs …)" Prowlarr spam — that 2024 was the series year baked into the query string.
🧪 Tests
- New: the 2026 issue-year override must reach both the query builder (generateSearchQueries year arg) and the year filter (GetComics seriesYear / Prowlarr seriesYear args) — not the 2024 series year.
✅ Verification
- tsc clean; vitest 297 passed (+1)