* fix(metadata): stop manual rematch from resurrecting recorded stale IDs
The Apply Match flow (ModeIdentify) re-injected durable provider IDs into
the identify request without checking stale_media_ids, so a known-dead
tmdb ID rode along, 404ed again during the Phase-2 fetch, and was
re-recorded with a fresh last_seen_at — the item never left the Stale
External IDs list and jumped back to the top after every rematch.
Filter recorded-stale IDs out of the injected durable set in
prepareProcessRequest. Caller-supplied IDs are untouched, so an admin
deliberately re-selecting a previously-stale ID still retries it (which
is also why the ModeIdentify suppression guard in processInternal stays).
Fixes#268
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(metadata): normalize provider-id keys so stale-ID suppression can't be bypassed by casing
Review on PR #276 flagged that suppressRecordedStaleProviderIDs lowercases
and trims the stored stale row's provider before looking it up in the
incoming map, while the map keys are used verbatim, and that
HandleApplyItemMatch passes req.ProviderIDs from the JSON body straight
into metadata.Process without the normalization the search endpoint
applies. A caller-supplied key like "TMDB" or " tmdb " therefore defeated
the suppression. The same normalization gap was previously flagged on
PR #182.
Fix both layers:
- HandleApplyItemMatch now runs req.ProviderIDs through
normalizeMatchProviderIDs (same semantics as the search endpoint) and
returns 400 when no non-blank entries remain, mirroring the existing
empty-map rejection.
- suppressRecordedStaleProviderIDs now indexes the incoming map by
normalized key and deletes the matching original keys, so suppression
is robust regardless of caller casing or padding.
Adds regression tests at both layers: a metadata-level case where the
durable row arrives as "TMDB " while the stale row records "tmdb", and
handler-level cases asserting apply normalizes keys/values and rejects
all-blank provider-id maps.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: Quick <31828688+Quick104@users.noreply.github.com>