2 Commits (048e4e85d5ceb6bbb9f6a6d2b2efbc259cc331ff)

Author	SHA1	Message	Date
Broque Thomas	4c11375930	Repair job card badge — show pending count, not last-scan count ... Discord report: Duplicate Detector card said "372 findings" and Cover Art Filler said "60 findings", but clicking the Findings tab's Pending filter showed 0. User read it as "findings aren't being created" — looked like a detector bug. Actual cause: the badge sourced ``last_run.findings_created`` (historical "found in last scan") without considering current state. After the user (or bulk-fix automation) resolved or dismissed those findings, they no longer appeared on the Pending tab — but the badge kept showing the last-scan number in red urgent styling. Backend was correct end-to-end: detectors create pending rows, bulk-fix moves them to resolved, Findings tab filters by status. Only the badge display lied about current state. Fix: - ``RepairWorker._get_pending_count_by_job()`` — single SQL aggregation returning ``{job_id: pending_count}`` for every job with pending findings. O(1) lookup per job instead of N round trips. - ``get_all_job_info()`` calls it once per request and adds ``pending_findings_count`` to each job's API response. - ``enrichment.js`` job card now branches on the count: - ``> 0`` → red ``"X pending"`` badge (urgent, action needed) - ``= 0`` AND last scan found something → muted grey ``"X found in last scan"`` (historical context, no action needed) - New CSS class ``.repair-flow-badge.findings-historical`` for the muted slate color so the two states are visually distinct. User-visible result with the screenshotted state (372 dup / 60 cover- art findings, all resolved): - Before: red "372 findings" / "60 findings" — implied 432 things to do, but Findings tab showed 0 pending - After: grey "372 found in last scan" / "60 found in last scan" — the badge text tells the user the count is historical, no surprise when Pending is empty Tests: 3 new tests in ``tests/test_create_finding_dedup_counter.py`` pin the per-job pending count helper: - returns ``{job_id: count}`` based on status='pending' rows only; resolved + dismissed rows excluded - empty dict when no pending findings exist - gracefully returns ``{}`` on DB error (badge falls back to historical count via the existing JS ``or 0`` safety) 2188/2188 full suite green. Pure UI/state-display fix — no detector logic, no backend behavior change.	1 month ago
Broque Thomas	cf5461f2f1	Fix: maintenance findings badge inflated when scan dedup-skipped ... `_create_finding` silently dedup-skipped re-discovered issues but the caller incremented `findings_created` regardless. So a re-scan that found the same issues as a prior scan reported 364 findings in the badge while 0 NEW pending rows hit the db, leaving the findings tab empty. `_create_finding` now returns bool (True on insert, False on dedup-skip / db error). All 16 repair jobs updated to only increment `findings_created` on True. Added `findings_skipped_dedup` counter surfaced in scan log: "Done: X scanned, 0 fixed, 0 findings (363 already existed), 0 errors". Also fixed a missing `job_id` kwarg in album_tag_consistency that was silently breaking finding creation for that scan.	1 month ago