Activity search + RecoverySweep fix + tagger_predictions shrink (#762, #764) + backup polish #91

Merged

bvandeusen merged 6 commits from dev into main 2026-06-10 14:33:35 -04:00

Conversation 0 Commits 6 Files Changed 25

+616 -50

bvandeusen commented 2026-06-10 14:33:27 -04:00

Owner

Copy Link

Copy Source

Batch of dev work since the last main cut:

• Activity tab search/filter (70d4017) — client-side search on Recent failures; server-side task-name search on All recent activity.
• Phantom RecoverySweep fix (9ba3db7, #762) — the download queue was missing its sweep-threshold override, so healthy 5–25 min Patreon walks were flagged as failures. Added download: 30 + a guard test.
• tagger_predictions shrink (3f92669, c8b815a, d55e52a, #764) — root cause of the 100 GB DB / #739 backup timeout. tagger_store_floor is now a DB-backed ML setting (default 0.70, was a 0.05 env floor); all consumers reconciled (suggestion thresholds, allowlist clamp); new "Prune predictions now" maintenance task drops the sub-0.70 tail from existing rows.
• Backup polish (7a40a50, #739) — pg_dump -Fc compressed dumps + pg_restore; reconciled the subprocess timeouts to sit under the Celery soft limits.

CI green on dev head 7a40a50 (run 831).

🤖 Generated with Claude Code

Batch of dev work since the last main cut: - **Activity tab search/filter** (`70d4017`) — client-side search on Recent failures; server-side task-name search on All recent activity. - **Phantom RecoverySweep fix** (`9ba3db7`, #762) — the `download` queue was missing its sweep-threshold override, so healthy 5–25 min Patreon walks were flagged as failures. Added `download: 30` + a guard test. - **`tagger_predictions` shrink** (`3f92669`, `c8b815a`, `d55e52a`, #764) — root cause of the 100 GB DB / #739 backup timeout. `tagger_store_floor` is now a DB-backed ML setting (default 0.70, was a 0.05 env floor); all consumers reconciled (suggestion thresholds, allowlist clamp); new "Prune predictions now" maintenance task drops the sub-0.70 tail from existing rows. - **Backup polish** (`7a40a50`, #739) — pg_dump `-Fc` compressed dumps + `pg_restore`; reconciled the subprocess timeouts to sit under the Celery soft limits. CI green on dev head `7a40a50` (run 831). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

bvandeusen added 6 commits 2026-06-10 14:33:27 -04:00

feat(activity): search/filter on both Activity-tab panes ... 70d4017cf6

Recent failures gains a client-side search over the already-loaded 24h
rows (task/queue/target/error), shown as a filtered/total count alongside
the existing error-type chips. All recent activity gains a debounced
server-side task-name search (new `task` ILIKE param on /runs) so it
spans the full history, not just the loaded page. LIKE wildcards are
escaped so task names' literal underscores match literally.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

fix(maintenance): download queue needs a sweep threshold above its 25-min time_limit ... 9ba3db75fd

recover_stalled_task_runs used the 5-min default for the download queue,
but download_source legitimately walks up to DOWNLOAD_HARD_TIME_LIMIT
(1500s = 25m). Healthy in-flight Patreon/gallery-dl walks were flagged as
phantom 'RecoverySweep' failures — visible in System Activity but absent
from the Subscriptions view (the download finished ok, reset the source's
consecutive_failures; only the orphaned task_run kept the stamp, since
_finalize only updates rows still 'running').

Add download:30 to QUEUE_STUCK_THRESHOLD_MINUTES — clears the 25-min hard
limit with buffer and matches DOWNLOAD_STALL_THRESHOLD_MINUTES so a real
hard kill is swept by the task-run and event sweeps together. Restores the
documented invariant (every override >= task time_limit). Regression test
pins the threshold above the hard limit so a future limit bump can't
silently re-break it.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

feat(ml): DB-backed tagger_store_floor (default 0.70), the ingest confidence floor ... 3f92669f12

Promotes the prediction store-floor from the TAGGER_STORE_FLOOR env (default
0.05) to a DB-backed, Settings-UI-tunable ml_settings column (default 0.70).
Storing every tag down to 0.05 from a ~10k-tag tagger is what grew
image_record's TOAST to ~100 GB; the suggestion path already filters at 0.70
and the centroid/learned path covers lower-confidence preferred tags, so the
sub-0.70 tail is redundant. Foundation for plan-task #764 (backfill + reclaim
land next; this only changes the write gate for NEW imports).

- ml_settings.tagger_store_floor (migration 0044, default 0.70)
- tagger.Tagger.infer(store_floor=...); ml task passes settings.tagger_store_floor
- ML admin GET/PATCH expose it; PATCH rejects a category suggestion threshold
  below the floor (nothing below the floor is stored, so the gap surfaces
  nothing) — server backstop for the UI slider clamp
- Settings → ML: store-floor slider + caption; category sliders min-bound to it

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

feat(ml): clamp allowlist min_confidence to the tagger store floor ... c8b815afe6

Consumer #4 of the store-floor change (#764). An allowlist tag can't
auto-apply more permissively than the ingest floor — predictions below
tagger_store_floor aren't stored, so a lower min_confidence behaves
identically to the floor. update_threshold now clamps to max(value, floor);
the AllowlistTable confidence input min-binds to the live floor and clamps
on edit. Keeps the stored threshold honest about actual apply behavior.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

feat(admin): prune_low_confidence_predictions backfill task + UI (#764) ... d55e52ae9b

The one-time backfill that actually shrinks the DB: drops stored
tagger_predictions entries below ml_settings.tagger_store_floor from every
image_record row, and clamps any allowlist min_confidence below the floor up
to it. Keep predicate (confidence >= floor) mirrors Tagger.infer's store gate
so backfilled rows match new imports. Keyset by id ASC, idempotent,
self-resumes on the soft time limit; runs on the maintenance_long lane.

pg_dump copies live data only, so this alone fixes the #739 backup timeout —
the reclaim (VACUUM FULL / pg_repack on image_record) is a separate, optional
disk-return step, brief because post-prune the live data is tiny.

- admin.prune_low_confidence_predictions_task + POST /api/admin/maintenance/prune-predictions
- PrunePredictionsCard in the Maintenance panel (shows the current floor)
- tests: registration + prune-keeps->=floor/drops-<floor + allowlist clamp

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

fix(backup): compressed -Fc dumps + pg_restore; reconcile subprocess timeouts (#739) ... 7a40a50fe9

DB backup polish (plan-task #764 Q3):
- pg_dump now uses custom format (-Fc): compressed (much smaller on NFS) and
  restored via pg_restore. Artifact extension .sql → .dump; restore_db swaps
  psql -f for pg_restore -d. BackupRun.sql_path field name kept (it's just the
  db artifact path).
- Reconcile the subprocess guardrails: the DB timeout was 720s with a stale
  'Celery soft is 10 min' comment, but backup_db_task's soft limit is actually
  1800s — so the bounded-kill fired 18 min early. Set DB=1700s / images=21000s,
  each just under its task's Celery soft limit so _run_bounded stays the
  primary guard (an NFS D-state hang defeats Celery's own SIGKILL).

Real shrink of the DB is the #764 prune; this makes each dump smaller/faster
on top of that.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

bvandeusen merged commit 5447fab987 into main 2026-06-10 14:33:35 -04:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

renovate-bot bvandeusen

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bvandeusen/FabledCurator#91