From 07e3ea37378839934e833bf6c13a7ca5713995c0 Mon Sep 17 00:00:00 2001 From: npeter83 Date: Thu, 17 Sep 2026 23:45:29 +0200 Subject: [PATCH] docs: the deep-backfill card counts the backlog, not the next pass Two reviewers in a row read the admin card's selection against `run_deep_backfill`'s, saw it was missing the job's `recent_synced_at` filter, and called it a card that counts channels the job will never touch. It is the opposite: the card is the same backlog figure /api/sync/my-status shows the user, and a channel still missing its recent pull is one the same job tick fetches first. Narrowing it would hide genuinely queued work. Written down where the next reader will look. --- backend/app/routes/scheduler.py | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/backend/app/routes/scheduler.py b/backend/app/routes/scheduler.py index 0683afaa..bf547483 100644 --- a/backend/app/routes/scheduler.py +++ b/backend/app/routes/scheduler.py @@ -145,6 +145,10 @@ def get_scheduler(_: User = Depends(admin_user), db: Session = Depends(get_db)) .where(Channel.recent_synced_at.is_(None), followed_channel()) ) or 0, + # The whole opted-in BACKLOG, deliberately not `run_deep_backfill`'s next-pass selection + # (which also wants `recent_synced_at`): the same figure /api/sync/my-status shows the user, + # and a channel missing its recent pull is one the same job tick fetches first, not one the + # job will never touch. Narrowing it here would under-report work that is genuinely queued. "channels_deep_pending": deep_eta["channels_pending"], "deep_eta_seconds": deep_eta["eta_seconds"], "videos_pending_enrich": db.scalar(