Task Selection Strategies

Order eligible tasks when workers claim a batch

Task Selection Strategies

Task selection is a global queue setting for all task types. It determines claim order, not completion order across concurrent workers.

Strategy	Eligible task order
fifo (default)	Oldest creation time first
lifo	Newest creation time first
priority	Highest integer priority first, then oldest creation time

DAEMON_TASK_SELECTION=priority ./target/release/task-daemon --config handlers.toml
# Or use the CLI flag:
./target/release/task-daemon --task-selection priority --config handlers.toml

In Docker, set DAEMON_TASK_SELECTION on the persistent deployment.

Priority Submission

HTTP accepts an integer priority, default 50. Higher values are selected first under the priority strategy. Values such as 0, 50, and 100 can be useful conventions, but the API does not enforce a 0–100 range.

curl -fsS -X POST http://localhost:8080/queue \
  -H "Content-Type: application/json" \
  -d '{"type":"urgent","data":{"message":"process soon"},"priority":100}'

The current gRPC request has no priority field and submits at priority 50. The library supports TaskService::queue_task_with_priority(task_type, data, priority).

Batches, Visibility, and Recovery

A worker atomically claims up to DAEMON_BATCH_SIZE tasks (default 5), then executes that batch sequentially. An arriving urgent task cannot preempt reserved Processing claims. Large batches reduce claim transactions but can delay newer tasks; compare latency as well as throughput when tuning.

Pending retries become eligible when their stored visibility time arrives. Processing claims become eligible for crash recovery after five minutes without renewal. SQLite applies the same global strategy to visible Pending tasks and expired Processing claims, with atomic claims preventing concurrent workers from taking the same eligible row. Hybrid uses this durable path as well.

FIFO does not ensure completion order when handlers have different runtimes or workers execute concurrently. LIFO and priority can indefinitely delay older or lower-priority work while newer or higher-priority work continues arriving. Choose according to your workload, and make handlers safe for recovery’s at-least-once execution.