bot-backend
af2b540ac2
Root cause: migration 090 used ON CONFLICT (source) DO NOTHING; prod already had a row source='deactivate_stale_avito' with enabled=false (inserted before 090 ran), so the INSERT was silently skipped. The scheduler's WHERE enabled=true filter meant the task never fired (last_run_id=NULL, next_run_at=2026-06-01 expired). Fix: add migration 100 — idempotent UPDATE SET enabled=true, next_run_at=NOW() WHERE source='deactivate_stale_avito' AND enabled=false. Safe to re-run: 0 rows matched once the row is already enabled. Auto-applied on next deploy via _schema_migrations tracking in deploy-tradein.yml. Migration 090 seed (enabled=true + ON CONFLICT DO NOTHING) is already correct for fresh installs — no change needed there. Tests: 7 new assertions in test_deactivate_stale_avito.py for migration 100 (exists, UPDATE source, SET enabled=true, idempotent guard, BEGIN/COMMIT, no psycopg trap, next_run_at reset). 39 tests pass total. Refs #759
19 lines
913 B
PL/PgSQL
19 lines
913 B
PL/PgSQL
-- #759: deactivate_stale_avito schedule seeded enabled=false → task never ran on prod.
|
|
--
|
|
-- Root cause: migration 090 (ON CONFLICT (source) DO NOTHING) was a no-op because
|
|
-- the row 'deactivate_stale_avito' already existed in scrape_schedules with
|
|
-- enabled=false when 090 ran on prod (inserted by a pre-release iteration or manual
|
|
-- seed). The scheduler's WHERE enabled=true filter excluded it on every tick, so
|
|
-- last_run_id stayed NULL and next_run_at=2026-06-01 expired without any runs.
|
|
--
|
|
-- Fix: idempotent UPDATE that only fires when the row is still disabled.
|
|
-- Re-running this migration after the row is already enabled → 0 rows matched, safe.
|
|
--
|
|
-- No bind params → no CAST(:x AS type) needed; BEGIN/COMMIT per sql.md conventions.
|
|
BEGIN;
|
|
UPDATE scrape_schedules
|
|
SET enabled = true,
|
|
next_run_at = NOW()
|
|
WHERE source = 'deactivate_stale_avito'
|
|
AND enabled = false;
|
|
COMMIT;
|