worker_ready signal handler was NOT firing in our setup (verified via DB breadcrumb after 3 deploys — zero rows of stage='worker_ready' in nspd_geo_log). Root cause of unreliability unknown — possibly Celery internals, possibly compose recreate timing. Either way, after every redeploy users had to manually cancel/resume jobs to keep them moving. Replace signal-based resume with periodic beat task: - cleanup_zombies runs every minute (* * * * *) - Finds nspd_geo_jobs in status running/paused with heartbeat >2 min stale - Sets status='queued' + apply_async with queue=geo - Idempotent — if no zombies, no-op worker_ready handler kept (with FK-fix breadcrumb on NULL job_id) for diagnostic purposes — if signal ever does fire, we'll have evidence. |
||
|---|---|---|
| .. | ||
| alembic | ||
| app | ||
| db/init | ||
| output | ||
| tests | ||
| .dockerignore | ||
| .env.example | ||
| .env.runtime.example | ||
| alembic.ini | ||
| debug.log | ||
| Dockerfile | ||
| pyproject.toml | ||
| uv.lock | ||