From 67032d9afacf63e058fab46e1712cc85e2bcd193 Mon Sep 17 00:00:00 2001 From: Edouard Vanbelle Date: Sun, 30 Aug 2026 21:58:33 +0200 Subject: [PATCH] fix(transcode): transcode_import is on-demand, like its thumbnail twins It was still registered on a 24h tick while the thumbnail imports moved to on-demand. The same reasoning applies and I missed it: the boot run in repair mode is the migration, nothing writes to that tree any more so the tail cannot grow afterwards, and a tick could not finish the job regardless because ticks never pass `repair`. Once drained it was a `read_dir` returning nothing, daily, forever. Co-Authored-By: Claude Opus 5 (1M context) --- .../services/transcode_import_service.rs | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/src/infrastructure/services/transcode_import_service.rs b/src/infrastructure/services/transcode_import_service.rs index 27c6963d..e1464c54 100644 --- a/src/infrastructure/services/transcode_import_service.rs +++ b/src/infrastructure/services/transcode_import_service.rs @@ -86,16 +86,14 @@ impl TranscodeImport { registry: &JobRegistry, provider: &Arc, ) -> Arc { - // Daily, matching the thumbnail imports: idempotent and resumable, - // so periodic is safe, and a migration nobody remembers to trigger - // never finishes. The tick imports but does not delete — `repair` - // defaults false. + // On-demand, matching the thumbnail imports. The boot run in repair + // mode IS the migration: nothing writes a hash-keyed entry here any + // more, so the tail cannot grow after startup, and a periodic tick + // could not finish the job anyway because ticks never pass + // `repair`. Once drained it would be a `read_dir` returning + // nothing, every day, forever. registry - .register_recoverable_job( - self.clone(), - provider.clone(), - Some(std::time::Duration::from_secs(24 * 3600)), - ) + .register_recoverable_job(self.clone(), provider.clone(), None) .await; self }