Scheduled command silently skipped when target worker is offline – 'Last run' still advances #9

Open
opened 2026-09-08 20:57:21 -04:00 by jared · 0 comments
Owner

Overview

processScheduledCommands() claims the slot (last_run = NOW(), next_run advanced) and then loops over worker_ids; a worker that is not connected is simply skipped with no execution record, no log line and no UI signal. The Scheduler tab then shows a fresh Last run timestamp, which reads as "it ran fine".

The same applies when the worker id stored in worker_ids no longer exists (worker deleted and re-registered under a new id).

Where

  • server.js processScheduledCommands()if (workerWs && readyState === OPEN) { … } with no else branch.

Suggested fix

  • Create a failed execution with a worker_offline log entry for each unreachable worker so it shows up in the Automated tab.
  • Track last_status / last_error on scheduled_commands and render it (✓ ran / ✗ worker offline) next to Last run.
  • Optionally notify via toast/webhook.
## Overview `processScheduledCommands()` claims the slot (`last_run = NOW()`, `next_run` advanced) and then loops over `worker_ids`; a worker that is not connected is simply skipped with no execution record, no log line and no UI signal. The Scheduler tab then shows a fresh **Last run** timestamp, which reads as "it ran fine". The same applies when the worker id stored in `worker_ids` no longer exists (worker deleted and re-registered under a new id). ## Where - `server.js` `processScheduledCommands()` – `if (workerWs && readyState === OPEN) { … }` with no else branch. ## Suggested fix - Create a `failed` execution with a `worker_offline` log entry for each unreachable worker so it shows up in the Automated tab. - Track `last_status` / `last_error` on `scheduled_commands` and render it (✓ ran / ✗ worker offline) next to Last run. - Optionally notify via toast/webhook.
jared added the buguxbackendschedulerpriority/high labels 2026-09-08 20:57:21 -04:00
Sign in to join this conversation.