org-subscriber: QueueDrainer never records queue-drained runs in the run ledger (start_run missing)

Mark commented

2026-08-21 22:03:37 +00:00

Owner

Bug: runs dispatched via the daemon's pending_queue (QueueDrainer path, dispatch.py drain_tick) never land in ~/.hermes/org-subscriber-ledger.db runs table with status=success. drain_tick calls AsyncDispatcher.dispatch + RunMonitor then complete_run on exit, but never calls ledger.start_run first — complete_run silently no-ops on unknown run_id (warns and returns False). Direct-registry dispatch (action_chain.py:207) does call start_run, so only the queue path is broken.

Impact: the Janitor + catch-up cadence (workers/reconcile.sh, workers/healthcheck.sh, enabled 2026-08-21 via Hermes cron org-mode-reconcile/org-mode-healthcheck) enqueues runs through pending_queue; without this fix every run executes (worker log lands in ~/.hermes/cron-runs//) but the ledger shows nothing. This blocked vikunja#114 acceptance 2 (runs must land in the ledger with status=success).

Fix (applied on deployed host unstable 2026-08-21, uncommitted): in drain_tick after dispatch, insert:
try:
self._ledger.start_run(run_id, worker, entry.get("room_id", "") or "", command, proc.pid, log_path, entry.get("source", "matrix"))
except Exception:
logger.exception("QueueDrainer: start_run failed for %s", run_id)

Verified on unstable: enqueued cron-run reconcile.sh + healthcheck.sh now record status=success with exit_code=0, elapsed_seconds populated. The patch is uncommitted in the deployed tree (git diff src/server/dispatch.py) — commit to upstream before next deploy or the defect silently returns.

Related deployed-but-uncommitted worker fixes (same cadence): workers/healthcheck.sh DAEMON_URL default 127.0.0.1:8080 -> 9090 (daemon listens on 9090) and check() now implements "warn" status so skipped optional checks (Matrix HS) no longer report degraded. Source: kanban tasker t_b7f7b115 / vikunja#114.

Bug: runs dispatched via the daemon's pending_queue (QueueDrainer path, dispatch.py drain_tick) never land in ~/.hermes/org-subscriber-ledger.db runs table with status=success. drain_tick calls AsyncDispatcher.dispatch + RunMonitor then complete_run on exit, but never calls ledger.start_run first — complete_run silently no-ops on unknown run_id (warns and returns False). Direct-registry dispatch (action_chain.py:207) does call start_run, so only the queue path is broken. Impact: the Janitor + catch-up cadence (workers/reconcile.sh, workers/healthcheck.sh, enabled 2026-08-21 via Hermes cron org-mode-reconcile/org-mode-healthcheck) enqueues runs through pending_queue; without this fix every run executes (worker log lands in ~/.hermes/cron-runs/<worker>/) but the ledger shows nothing. This blocked vikunja#114 acceptance 2 (runs must land in the ledger with status=success). Fix (applied on deployed host unstable 2026-08-21, uncommitted): in drain_tick after dispatch, insert: try: self._ledger.start_run(run_id, worker, entry.get("room_id", "") or "", command, proc.pid, log_path, entry.get("source", "matrix")) except Exception: logger.exception("QueueDrainer: start_run failed for %s", run_id) Verified on unstable: enqueued cron-run reconcile.sh + healthcheck.sh now record status=success with exit_code=0, elapsed_seconds populated. The patch is uncommitted in the deployed tree (git diff src/server/dispatch.py) — commit to upstream before next deploy or the defect silently returns. Related deployed-but-uncommitted worker fixes (same cadence): workers/healthcheck.sh DAEMON_URL default 127.0.0.1:8080 -> 9090 (daemon listens on 9090) and check() now implements "warn" status so skipped optional checks (Matrix HS) no longer report degraded. Source: kanban tasker t_b7f7b115 / vikunja#114.