Telegram imports fixed: scan the FILE, not the folder (#44, #45)
Telegram downloads completed but Radarr never imported them — Scan imported nothing for movie NNNN within 120s. Root cause: v1.2.0's release notes shipped the wrong rule. Commit 9bff467 switched DownloadedMoviesScan from the file path to the drop folder on a wrong assumption, and folder-path scans silently import nothing.
Measured live on Radarr 6.4.4 (production, 2026-10-04):
-
File-path scan (
D:\Eziarr\Title (Year).mp4, importMode Move) → imports the single file,hasFileflips true, Move consumes it out of the drop folder ✅ -
Folder-path scan (
D:\Eziarr) → command "completed" in <5s, imports nothing for flat drop-folder files ❌ -
POST /api/v3/manualimport→ dead end: 200 OK but imports nothing ❌ -
buildScanCommand({service, serviceId, filePath})now requires the file path and throws without it; worker passesresult.filePath(correct on fresh downloads and import-only retries). -
verifyArrImportkept untouched — its hasFile poll is what surfaced this regression as a clear failure instead of a hollow success. -
No folder-scan fallback — single honest path (deliberate decision).
-
Regression test added so the scan shape cannot silently drift back.
Three orphaned downloads (Tiada Tajuk 2133, Keluang Man 2283, Langit Cinta 2249) were recovered without re-downloading.
Verification
bun test→ 65 pass / 0 fail, 8 files on the promoted tip.- Container smoke test (2026-10-04): image built from staging, isolated container with the real drop-folder mount; drove the real
triggerArrImport+verifyArrImportagainst production Radarr on an unmonitored test movie →{"imported":true}in ~5s; drop folder consumed; Radarr state restored afterwards. - Tester gotcha recorded: Radarr permanently rejects small files as "Sample" (747KB/12s and 12MB/200s both rejected, 70MB/600s passed) — smoke-test files must be >~20MB, and rejection reasons are only visible via the manualimport preview endpoint.
Housekeeping
- Version bump to 1.3.0.