OutlabsTaskq
Operations

Housekeeping

Tick, lease reaping, schedule firing, and wake behavior.

Tick and lease reaping

taskq.tick() is advisory-lock-deduped maintenance. It reaps expired leases and performs related bounded cleanup. Lease reaping remains a core correctness path for stolen or expired attempts.

The standalone taskq scheduler run calls tick() before evaluating due schedules in both continuous and --once modes. It therefore owns housekeeping and schedule advancement as one supervised production process.

Do not run the standalone scheduler and an embedded FastAPI schedule loop as independent owners. During migration, disable the old loop only after the standalone scheduler has passed doctor and produced advancement evidence.

Schedule firing remains part of the current 0.1.0a36 surface; its original contract was introduced in migration 0010.

TaskqRuntime / taskq_lifespan remains a compatibility adapter for hosts that temporarily need facade-owned housekeeping. It uses the same target-attested core, but tying scheduler health to API replicas is no longer the recommended production topology.

Schedule firing

The scheduler claims fenced schedule rows, evaluates recurrence using database time, writes a durable decision, and atomically creates ordinary queued jobs. Application workers—not housekeeping—run task handlers.

ConcernOwner
Recurrence and due-time evaluationStandalone scheduler
Lease reaping and bounded tick workStandalone scheduler
Task handler executionApplication worker
API request servingHost API / optional TaskQ facade

Schedule firing first shipped in migration 0010. The standalone, target-attested scheduler and durable decision model ship in 00190020 and remain part of package 0.1.0a36.

Wake path

Polling is correctness. NOTIFY is latency.

DSN workers may LISTEN for early wakeups (WorkerSettings.listen, default true). Missed notifications never lose jobs. HTTP workers cannot listen; they poll and may use claim-wait long-polling on the facade.

The scheduler itself polls database time with bounded jitter and backoff. A notification is never required for schedule correctness.

Soft stop

On SIGTERM, workers stop claiming, wait up to soft_stop_timeout, hard-cancel remaining handlers, and release running work with a shutdown cause.

The scheduler begins no new claim after shutdown is requested and lets the current SQL transaction finish.