Workers and replay

Asynchronous work runs in a separate process:

npm run worker

Scheduling

Repeatable work is registered through BullMQ's scheduler API with a stable schedule id, so restarting the worker — or running a second replica — neither duplicates nor loses a schedule. Each scheduled iteration is visible in the queue as a delayed job.

Two guards make silent schedule loss visible:

• the worker surfaces queue errors instead of swallowing them;
• a watchdog reports a schedule that has stopped advancing as schedule_stalled.

Liveness

Worker liveness is reported through GET /api/health, which marks the worker unavailable when its heartbeat stops. The worker is a separate process and can run on its own host; if it stops, queued work waits rather than being lost, and health reflects it.

Execution semantics

Workers run with bounded retries, backoff, timeouts, leases, cancellation, dead-letter handling, and correlation IDs.

Replay

Replays stay scoped to the authorized organization/client/connection and preserve idempotency. For source ingestion, canonical persistence must occur before a synchronization checkpoint is treated as successfully advanced.