26 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	32cac46b8b	fix: the import recovery sweep no longer fails queued files that are waiting their turn ... The orphan sweep in recover_interrupted_tasks failed every 'queued' row older than 30 minutes. A queued row has its broker message, so in a batch bigger than half an hour of work the sweep failed the whole tail: a library import of 8,135 files lost 3,114 that way. Never-enqueued 'pending' rows are still swept after 30 minutes; a 'queued' row is swept only when the broker's import queue is empty, and is kept when the queue can't be read. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-06 16:28:04 -05:00
bvandeusenandClaude Opus 5.5	315399c4e5	fix: an unfinished download is never stored as an attachment, and the temp sweep keeps any file a library row points at ... The importer refuses a staging file (.part, .partial, .megatmp.*) at both entry points, the same way it refuses a sidecar .json, and discard_after_attach never deletes one: the age-gated temp sweep owns them. The sweep checks its stale candidates against image and attachment rows and keeps any a row points at. A Google Drive fetch's half-written file had been stored as <sha>.part; the sweep then deleted it by name and left the row with no file. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-06 15:48:14 -05:00
bvandeusenandClaude Opus 5.5	2fc71cfe4e	feat: Cleanup can import files that are on disk but not in the library ... A download writes its files into the artist's folder and imports them in a later step. A run that stopped in between left complete files no record points at, and a walk that had already marked them seen never returned for them; on the live instance that is about 95 GB of art. "Import files the library is missing" (Cleanup, Duplicates & leftovers) walks every folder named for an artist, matched by slug so a differently cased folder still matches, and lists the images, videos and archives no image, attachment or queued import points at. Stores, sidecars, staging files and files changed in the last day are left alone. Preview shows the counts per artist; Import queues the same list as a library import batch, whose tasks file the folder's post record, attach each file where it lies with its folder's artist and source, and remove the ones the library already holds or the import filters reject. A file whose import crashed is kept. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-06 10:31:37 -05:00
bvandeusenandClaude Opus 5.5	157f2803c0	fix: downloads stop leaving files on disk that the library doesn't use ... - An archive whose images were extracted was kept at its download path as well as in the attachments store. Both download paths now remove the downloaded copy. - A downloaded file the import filters reject (too small, transparent, single colour, unreadable) was left on disk with no record. A later walk found it, imported it again and rejected it again, every time. Rejected files are now removed; the seen ledger keeps them from being downloaded again. - Both paths share one policy, Importer.discard_after_attach, which never removes a file an ImageRecord points at. - An external-link fetch that fails, or whose worker was killed, left partial files (megatools' .megatmp.*) in the link's dir, and a killed fetch left its link 'downloading' for good. A fetch now clears unrecorded leftovers before starting and after failing. The sweep returns a link to retry once it has been 'downloading' past the task's hard limit, using a new external_link.started_at column (migration 0117). - The orphaned temp-file sweep now recognises .megatmp.* as well as .part and .partial. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-05 18:00:31 -05:00
bvandeusenandClaude Opus 5.5	e704c70f32	fix: the download boot hook imports a model-only module, keeping the membership roster off the fetch path (#4433) ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LVjrnpQjRgHdvq95rASoiR	2026-09-25 10:32:41 -04:00
bvandeusenandClaude Opus 5.5	0fad744bfb	fix: a restart no longer strands downloads — the download lane closes its predecessor's runs as interrupted and frees the platform locks at boot (#4433) ... A walk that outlives the 90s stop grace is SIGKILLed: its event never finalizes and its platform lock is held for the 27-min TTL. The 30-min sweep then errored every stranded event and bumped consecutive_failures, backing sources off (and blocking backfills) as if the platform failed. On worker_ready, the process consuming 'download' ends pre-boot pending/running events as skipped with error_type 'interrupted', leaves the source untouched so the next tick resumes it, and releases the serialized platforms' locks. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LVjrnpQjRgHdvq95rASoiR	2026-09-25 10:29:05 -04:00
bvandeusenandClaude Opus 5.5	23e062dd4a	test: the stall-sweep tests read the thresholds they check, and stay clear of the new import value (#4432) ... Run 7505 failed test_recover_stalled_task_runs_ml_queue_uses_longer_threshold. It restated the old 25-minute ml threshold as a 30-minute "stale" row, which is now inside the 40-minute window. The test now reads the value from QUEUE_STUCK_THRESHOLD_MINUTES. The archive test's fast-import row was exactly 10 minutes old, which is the new import threshold, so it passed only by the milliseconds between seeding and sweeping. It is now 15 minutes old. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LVjrnpQjRgHdvq95rASoiR	2026-09-25 09:51:42 -04:00
bvandeusenandClaude Opus 5.5	f2e4ee4d17	fix: beat takes each job's last run from task_run, so a redeploy no longer resets the schedule (4408) ... Beat's default scheduler kept its memory in a shelve file nothing persists, and a scheduler that remembers nothing waits a full interval before any job. Since the one-container image, every redeploy restarts beat, and no daily or weekly job had run since 2026-09-21 (cleanup, backup and download-event pruning, membership sync, thumbnail backfill, integrity check, vacuum). TaskRunScheduler seeds each entry's last_run_at at startup from task_run's newest start for that task: an overdue job runs at once, one not yet due waits the remainder, and one never recorded is due now. prune_task_runs now keeps each task's newest row however old, or a weekly job would look never-run a day after it ran and fire on every restart. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LVjrnpQjRgHdvq95rASoiR	2026-09-24 16:36:58 -04:00
bvandeusenandClaude Opus 5	2e0f8f8c61	feat(cleanup): reclaim orphaned attachments — rows and store blobs (#3068) ... PostAttachment's two FKs are both ON DELETE SET NULL, so a deleted post or artist left the row behind rather than taking it. Nothing ever pruned those rows, and nothing in the repo had ever unlinked a file under the attachment store — so both rows and bytes accumulated permanently, invisible to every existing diagnostic. Why a disk->DB reconciliation rather than a row sweep: the store is sha-addressed and idempotent, so ONE blob backs MANY rows. Deleting a row does not free its blob, and since the artist cascade (#3066) now deletes its attachment rows outright, a freed blob has no DB pointer left to find it by. Walking the store and asking "does any row still reference this sha?" catches orphans from every cause, including ones no future delete path will think to report. Preview and apply share `_orphan_attachment_conditions` (rule 93). The dry-run derives its surviving-sha set by NEGATING that same predicate, so it is honest about blobs the delete would free rather than counting them as still-referenced — the one place this was easy to get backwards, so it has its own parity test. Guards, each with a reason: - A blob is written before its row commits, so a just-stored file legitimately has no referencing row. Files under 6h are never judged — same guard and reasoning as ORPHAN_TEMP_MIN_AGE_HOURS. - `.partial` staging files belong to cleanup_orphaned_temp_files; skipped rather than raced. - The sha is parsed as the first 64 chars, not via Path.stem: store() takes the extension from the source filename, and a URL-encoded basename yields a multi-dot suffix that would make stem eat part of the sha. - A 900s walk budget reports partial=True instead of running to the task's hard limit (rule 89). - TASK_STUCK_THRESHOLD_MINUTES override at 30 (= time_limit 25 + 5). Without it a healthy 20-minute walk is phantom-flagged 'RecoverySweep' at the bare 5-min default — the #883 failure class; its invariant test is mirrored here. Defaults to the safe preview at both the task and the route, unlike the other maintenance triggers: this apply unlinks files. Operator-triggered only, never on a beat. Ships with its UI (rule 27): AttachmentReclaimCard in Cleanup → Duplicates & leftovers, built on the existing useMaintenanceTask/MaintenanceTile shapes, so a run survives navigating away. Surfaces files_failed and partial explicitly, since both change what the numbers mean. Also promotes humanBytes to utils/bytes.js — it was byte-identical in VideoDedupCard and GatedPurgeCard and this card would have been the third copy. The three divergent `formatBytes` helpers are deliberately left alone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-26 22:37:24 -04:00
bvandeusenandClaude Opus 4.8	0b78264d62	feat(maintenance): daily janitor for orphaned .part/.partial staging files ... Downloads/imports stage into <name>.part / <name>.partial then os.replace() into place, so a kill mid-write leaves a discardable temp — never a corrupt final. cleanup_orphaned_temp_files sweeps ones left behind under the images root, only older than 6h so an in-flight download's staging file is never removed. Daily beat. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-07 22:15:33 -04:00
bvandeusenandClaude Fable 5	19b962f1a7	feat(b3): ml-worker becomes optional — embed-only role, decoupled GPU coordination, cpu-embed switch ... The ml-worker's ONLY processing role is now the CPU whole-image embed fallback (tag_and_embed renamed embed_image — Camie tagging was retired #1189 and the name kept implying otherwise; videos were already handled agent-style: frame sampling + mean-pool). Detection/cropping/CCIP stay GPU-agent-only, and their completion is judged per-pipeline: ccip by gpu_job rows, siglip by concept regions at the current model version — never by image_record.siglip_embedding. A CPU embed therefore can NEVER close crop work for the agent (regression test pins this; only the whole-image 'embed' job, the same artifact, is satisfied). Making removal actually safe (operator will drop the container): - GPU-queue coordination (enqueue_gpu_backfill, recover_orphaned_gpu_jobs, reprocess_gpu_jobs) moved verbatim to tasks/gpu_queue.py on the maintenance quick lane — it lived on the 'ml' queue only by module colocation, which made the ml-worker a hard dependency of the whole agent pipeline. - New ml_settings.cpu_embed_enabled (migration 0074, default ON so agent-less installs keep working): OFF stops the four import hooks queueing embed work nothing will consume and no-ops the manual backfill; switch lives on the renamed 'CPU embedding backfill' card. - NB heads training / auto-apply still run on the ml image (sklearn) — a stack that removes the container gives those up too. Deploy note: in-flight messages under the old task names are dropped by the new workers; the 60s orphan sweep + hourly backfill re-fire under the new names immediately. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CDgx8bQS5YrGRK76v8HUnM	2026-07-02 16:53:08 -04:00
bvandeusenandClaude Opus 4.8	258c77dfcd	fix(maint): raise recovery-sweep threshold for fetch_external_link (#883) ... External file-host fetches run to a 60-min hard limit (time_limit=3600, per-fetch _FETCH_TIMEOUT=3000s), far longer than the recovery sweep's 5-min default. recover_stalled_task_runs was phantom-flagging healthy in-flight fetches as "RecoverySweep: no completion signal received within 5 min" before the task's own timeout/error handling could surface the real error (operator-flagged: target 414 swept at 6.6min). The sweep already has per-queue/per-task overrides for long tasks, but fetch_external_link was never added and its TaskRun records queue='default' (no queue override) despite external.* routing to download. Add a task-name override of 65 min (time_limit 60 + 5 buffer); task-name precedence makes it robust regardless of the recorded queue. No new internal timeout needed — the existing _FETCH_TIMEOUT + soft_time_limit + except-block log.exception already capture the real failure once the sweep stops preempting. Pinned tests: external-fetch override survives a 10-min row / flags a 70-min row on queue='default'; invariant guard asserts override >= hard time_limit. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-16 20:54:39 -04:00
bvandeusenandClaude Opus 4.8	9ba3db75fd	fix(maintenance): download queue needs a sweep threshold above its 25-min time_limit ... 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>	2026-06-10 11:57:31 -04:00
bvandeusenandClaude Opus 4.8	914033db29	feat(maintenance): scheduled + manual DB VACUUM ANALYZE + bloat readout ... The TABLESAMPLE showcase reads physical blocks (bloat-sensitive), and the periodic prune/backfill/recovery tasks churn dead tuples faster than autovacuum always keeps up — so explicit maintenance earns its keep here. - tasks.maintenance.vacuum_analyze: VACUUM (ANALYZE) over high-churn tables (VACUUM_TABLES) on an AUTOCOMMIT connection (VACUUM can't run in a txn). Scheduled weekly via Beat; also operator-triggerable. - _sync_engine.get_sync_engine(): expose the process engine for the autocommit connection. - GET /api/admin/maintenance/db-stats: per-table n_live/n_dead/dead_pct + last (auto)vacuum/analyze from pg_stat_user_tables — visibility, not a black box. - POST /api/admin/maintenance/vacuum: enqueue the task on demand. Tests: vacuum task runs + reports tables; db-stats shape; trigger queues. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-04 00:49:39 -04:00
bvandeusenandClaude Opus 4.7	e35fb1edf7	fix(scan): recovery sweep for stranded download events ... The scan tick (scan.py:_tick_due_sources_async) inserts DownloadEvent(status='pending') and fires download_source.delay(). If the task dies before finalizing the event — worker OOM/SIGKILL, lost task, or a gallery-dl that didn't unwind on the 1200s hard time_limit — the event stays in-flight forever. Every later tick then skips the source via the in-flight guard (scan.py:168), so Source.last_checked_at is never written and the operator sees "last check never" in the Subscriptions health column, permanently. cleanup_old_download_events only prunes terminal events (by design); no existing sweep covered the pending/running case. Operator confirmed 2026-05-29 with a diagnostic query: all 43 "never checked" sources were stranded behind stale in-flight events (eligible_stuck_inflight = 43, every other bucket zero). New recover_stalled_download_events task (Beat every 5 min): - Flips DownloadEvent rows pending/running > 30 min (10 min past the download_source 1200s hard kill, so legitimately-running tasks are never touched) to status='error' with a sentinel message. - Bumps each affected Source's consecutive_failures ONCE per source — backoff is 2^N on that counter so per-event bumps would needlessly inflate the next interval — sets last_error, stamps last_checked_at. UPDATE...RETURNING source_id avoids a SELECT-then-UPDATE-WHERE-IN that would hit the psycopg 65535-param ceiling on a large strand pile. Net: the 43 currently-stranded sources unstick on the first sweep after deploy, their health dots flip amber instead of unchecked, and the next scan tick re-queues them. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-29 21:40:52 -04:00
bvandeusen	e77afe8295	feat(import-resilience L1): poison-pill circuit breaker — cap stuck-task re-queues ... Layer 1 of the import-task resilience work (operator-requested 2026-05-28). The recover_interrupted_tasks sweep re-queues rows stuck in 'processing' — correct for a worker crash, but without a cap a row that RELIABLY hard-crashes the worker (OOM/segfault/SIGKILL on a corrupt or oversized input) loops forever: re-queue → crash → re-queue, burning a worker slot every 5 min. A caught exception flips to terminal 'failed' and never enters this loop; only process-killing inputs do. - alembic 0026: import_task.recovery_count (int, default 0) + import_task.refetched (bool, default false — backs Layer 2). - recover_interrupted_tasks now runs a poison-pill UPDATE FIRST: stuck rows whose recovery_count has already reached MAX_RECOVERY_ATTEMPTS-1 are marked 'failed' with a diagnostic ("crashed or stalled the worker N times … likely a corrupt or oversized input … inspect/replace the file, then retry via /api/import/retry-failed") instead of re-queued. The re-queue pass then handles the remaining stuck rows and bumps recovery_count. Shared stuck_predicate (and_/or_) keeps the media-5min / archive-40min split. - MAX_RECOVERY_ATTEMPTS=3 (two recoveries then give up). The failed poison pill surfaces in the existing import-failures view with its file path, directly answering "help me identify them." Test test_recover_interrupted_poison_pill_caps_at_max pins both branches: a row at the cap is failed (not re-enqueued, diagnostic present), a row one short is re-queued + incremented.	2026-05-27 23:54:35 -04:00
bvandeusen	57a22d6098	fix(tests): repair test_maintenance — skips_fresh_running tail was orphaned at module scope by the inserted ml/archive sweep tests (F841/F821)	2026-05-27 23:06:00 -04:00
bvandeusen	a85880f965	fix(import): split archive imports into their own task + budget; archive-aware recovery sweeps ... Operator-flagged 2026-05-28: import_media_file on target 1645019 hit SoftTimeLimitExceeded at exactly 5.0 min. Their diagnosis was correct — the timeout covered the WHOLE archive, not per object. Importer._import_archive (importer.py:409) runs the full per-member pipeline (sha256 + pHash + dedup query + copy + provenance) for EVERY media member inline, all under import_media_file's single 300s soft limit. A single media file is sub-second; a multi-hundred-member archive blows the budget. They shared one task name and one timeout. **Split archive into its own task** - New `import_archive_file` task: same body as import_media_file (dispatch is by file-kind inside Importer.import_one) but soft=30min / hard=35min. Shared `_run_import_task` helper holds the flip-to-processing + resilience-contract wrapper; both tasks call it. - New `enqueue_import(task_id, task_type)` router — single source of truth for media-vs-archive dispatch. Used by all three enqueue sites: scan_directory, /api/import/retry-failed, recover_interrupted_tasks. - scan_directory now sets ImportTask.task_type = "archive" when is_archive(entry) (the model field already existed, anticipating this; scan was hardcoding "media"). - import_archive_file routes to the existing 'import' queue via the task_routes `import_file.*` wildcard — no worker config change. **Archive-aware recovery sweeps** Both sweeps would otherwise preempt a legitimately-running archive: - recover_interrupted_tasks (ImportTask 'processing' sweep): now task-type-aware. Media stays at STUCK_THRESHOLD_MINUTES (5); archives get ARCHIVE_STUCK_THRESHOLD_MINUTES (40 = 5-min buffer past the 35-min hard limit). Single UPDATE with an OR predicate over the two (task_type, cutoff) pairs; requeue routes via enqueue_import. - recover_stalled_task_runs (TaskRun 'running' sweep): now supports per-task-name overrides (TASK_STUCK_THRESHOLD_MINUTES) layered above the per-queue overrides added for ml. import_archive_file gets 40 min while the 'import' queue stays at the 5-min default for single-file imports. Precedence: task_name → queue → default, each pass excluding rows claimed by a higher-precedence pass so every row is touched once. **Tests** - test_import_archive_file_registered - test_recover_stalled_task_runs_archive_task_uses_longer_threshold — pins that a 10-min archive task-run survives, a 50-min one is flagged, and a same-queue 10-min media import is flagged at the default. - _make_task_run gains queue= + task_name= params. After deploy: archive imports get a 30-min budget and aren't preempted by either sweep; single-file imports keep their tight 5-min detection.	2026-05-27 22:45:11 -04:00
bvandeusen	407de18ff6	fix(ml): video branch needs longer time limits; recovery sweep is now per-queue ... Operator-flagged 2026-05-28: tag_and_embed on image 6288 (an mp4) was marked failed by recover_stalled_task_runs at the 5-min sweep tick while still legitimately running. The error_type='RecoverySweep' / "no completion signal received within 5 min" message was misleading — the worker was busy, not stuck. Root cause is two interacting limits, both undersized for video work: tag_and_embed: soft_time_limit=300, time_limit=420 (sized for the image branch, ≈2 GPU ops) recovery sweep: STUCK_THRESHOLD_MINUTES = 5 across all queues The video branch samples 10 frames via ffmpeg, then runs tagger + embedder on EACH frame — ~20 GPU ops vs 2 for an image. A loaded ml-worker can take 5-10 min on a long video, which trips both limits well before the task naturally finishes. **Two-part fix** 1. `tag_and_embed` time limits bumped to soft=900 (15 min) / time=1200 (20 min). Sized for the video path's worst case; image runs return in seconds and don't care. 2. New `QUEUE_STUCK_THRESHOLD_MINUTES` override dict in maintenance.py. Queues with legitimately-long-running tasks (currently just `ml` at 25 min — 5-min buffer past the new hard kill) get their own threshold; queues not in the dict use the default 5 min. The sweep now issues one UPDATE per distinct threshold value, with `queue.notin_(override_queues)` on the default pass so each row is touched at most once. Tests: - _make_task_run helper accepts `queue=` (defaults to "default") so existing tests use the default-threshold path. - New test `test_recover_stalled_task_runs_ml_queue_uses_longer_threshold` pins both directions: a 10-min-old ml row survives (fresh by 25-min override), a 30-min-old ml row gets flagged. After deploy, operator's mp4 ML jobs run to completion without spurious RecoverySweep failures.	2026-05-27 22:23:35 -04:00
bvandeusenandClaude Opus 4.7	9d5abb09f6	fix(maintenance): recover_interrupted_tasks also sweeps pending/queued orphans (>30 min) to failed ... scan_directory creates ImportTask rows with status='pending' (commit) then in a second pass transitions to 'queued' + .delay() (commit). Crashes in that window leave rows orphaned with no recovery path. Operator hit 5490 such rows 2026-05-25; the existing sweep only handled 'processing'. Flipping to 'failed' (not re-enqueue) lets the operator drain via the existing /api/import/retry-failed endpoint at their own pace. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-25 02:00:29 -04:00
bvandeusenandClaude Opus 4.7	36611cbe00	fc3i: tests for recover_stalled_task_runs + prune_task_runs ... Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-24 21:07:01 -04:00
bvandeusenandClaude Opus 4.7	4437488899	fix(tests): unpin test_recover_interrupted_only_old from STUCK_THRESHOLD_MINUTES (was -5min fresh / now -30sec so threshold can move freely) ... Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-24 12:40:27 -04:00
bvandeusen	dfa6a5c895	fix(integration): lazy seed-snapshot (unblock unit job); isolate recover test from eager import	2026-05-15 22:43:46 -04:00
bvandeusenandClaude Opus 4.7	22bc24b6b6	fix(fc2a): align CI with FabledRulebook — lint + short unit tests only ... The CI failure resolving 'postgres' hostname was the symptom; the cause is that the workflow violated FabledRulebook/forgejo.md's "CI philosophy — lint + short unit tests only" rule. Integration tests against a real Postgres are supposed to run locally via docker-compose, not in CI. Changes: - Marked 8 DB-dependent test files with @pytest.mark.integration: test_tag_service, test_importer, test_gallery_service, test_api_gallery, test_api_tags, test_api_settings, test_api_import_admin, test_maintenance. - CI workflow drops the postgres/redis service containers and the alembic upgrade smoke step entirely. - Pytest invocation in CI changes to `pytest -v -m "not integration"`. - Added pytest marker registration to pyproject.toml. - DB_PASSWORD and SECRET_KEY env vars retained because config.py reads them at import time even though unit tests don't actually use them (set to placeholder values). What CI now runs: - ruff check - pytest on the 6 unit test files: test_slug, test_paths, test_migration_0002, test_thumbnailer, test_celery_smoke, test_tasks_register. - npm install + npm run build What CI no longer runs: - alembic upgrade (no live DB) - the 8 integration test files (these run locally via docker-compose) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-14 15:23:07 -04:00
bvandeusenandClaude Opus 4.7	b4e0d680f1	fix(fc2a): satisfy ruff 0.15.13 lint — UP017, UP042, I001 ... Ruff lint surfaced 23 violations across three rules; all addressed: UP017 (Use datetime.UTC alias): Replaced 13 sites of datetime.now(timezone.utc) with datetime.now(UTC), also adjusted from-imports accordingly. UTC is a Python 3.11+ alias for timezone.utc that ruff's pyupgrade rules prefer. UP042 (StrEnum): Replaced `class TagKind(str, Enum)` and `class SkipReason(str, Enum)` with `class Foo(StrEnum)`. StrEnum was added in Python 3.11 stdlib and is the modern idiom. Behavior is equivalent for our usage (the .value attribute, str(member) semantics). I001 (Import sorting): Added `known-first-party = ["backend"]` to ruff.toml's [lint.isort] so ruff groups `backend.*` imports correctly. Without it, ruff treated them as third-party and demanded a different grouping. The existing import order is stdlib → third-party → first-party → local relative, which ruff now accepts. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-14 14:11:35 -04:00
bvandeusenandClaude Opus 4.7	509c19ce86	feat(fc2a): add maintenance tasks (recovery + cleanup) with beat schedule ... recover_interrupted_tasks runs every 5 minutes, finds ImportTask rows stuck in 'processing' for >30 minutes (well above any legitimate import duration), and re-queues them. cleanup_old_tasks runs daily and deletes finished tasks older than 7 days so the task table stays an operational view rather than an archive. Both thresholds match ImageRepo's precedent. The 30-min stuck threshold is documented inline so a future reader can adjust it intentionally rather than mistaking it for a 'magic number'. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-14 12:09:09 -04:00