lekss361 ae86d62e9b fix(worker): worker_ready geo-resume blocked by early return in kn-resume ... Root cause of "auto-resume never fired": the kn_scrape_runs resume section hit `if not rows: return` (and similar `return` in except) before reaching the nspd_geo_jobs resume section. Whenever there were no zombie kn-runs (the normal case), the handler bailed out and geo jobs stayed forever 'running' with stale heartbeats — users had to manual cancel/resume after every deploy. Fix: don't return early. Initialize `ids = []`, only run UPDATE if rows exist, drop the inner `return` from exception branch. The for-loop over ids becomes a no-op when empty, and execution falls through to the geo section. Same pattern as the breadcrumb above — fail soft, continue. cleanup_zombies beat task (added in caa467f) stays as belt-and-suspenders in case worker_ready signal ever misbehaves again.		2026-05-11 17:12:31 +03:00
..
tasks	fix(worker): periodic zombie cleanup via beat instead of worker_ready	2026-05-11 17:02:29 +03:00
__init__.py	init	2026-04-25 13:45:19 +03:00
celery_app.py	fix(worker): worker_ready geo-resume blocked by early return in kn-resume	2026-05-11 17:12:31 +03:00