Worker configuration
Configure the worker through keyword arguments to Worker.new:
worker = Zeridion::Flare::Worker::Worker.new(
api_key: ENV["FLARE_API_KEY"], # falls back to FLARE_API_KEY
queues: ["email", "reports"], # defaults to the union of your jobs' queues
concurrency: 5,
poll_interval_s: 2.0,
default_timeout_s: 1800,
default_max_attempts: 3,
shutdown_grace_s: 30.0,
logger: Logger.new($stdout),
)
Options
| Keyword | Default | Meaning |
|---|---|---|
api_key: | ENV["FLARE_API_KEY"] | API key — pass directly or via the env var. |
base_url: | https://api.zeridion.com | Override for dev / staging. |
queues: | union of every registered job's queue | The queues to poll. |
concurrency: | 10 | Max jobs running at once. |
poll_interval_s: | 2.0 | Idle delay between empty polls. |
default_timeout_s: | 1800 | Timeout used when a job item carries none. |
default_max_attempts: | 3 | Default attempt ceiling. |
shutdown_grace_s: | 30.0 | Max time to await in-flight jobs while draining. |
hostname: | machine hostname | Hostname reported when announcing the worker. |
logger: | none (silent) | A Logger for runtime + per-job logs. |
Queues
If you don't pass queues:, the worker polls the union of every registered
job's queue. Pass an explicit list to poll a subset — for example to run a
dedicated worker fleet for one queue:
Zeridion::Flare::Worker::Worker.new(queues: ["email"])
Concurrency
concurrency: caps simultaneous jobs. The worker only requests as many jobs per
poll as it has free slots, so it never over-pulls. Because Ruby releases the
global lock during I/O, I/O-bound jobs run truly in parallel; CPU-bound jobs do
not, so for CPU work prefer a smaller concurrency: and more worker processes.
Timeouts
Each job carries its own timeout (from the job's flare_options timeout:, or the
value chosen when it was enqueued). default_timeout_s: only applies when a job
item arrives without one. When a job's timeout elapses, its cancellation handle
trips — a cooperative handler that checks ctx.cancelled? (or honors a socket
read timeout) stops promptly. See Cancellation & timeouts.
Logging
Pass any Logger. The worker emits structured lifecycle lines (worker starting,
job executing, job succeeded/failed, drain) and binds the same logger to
ctx.logger so your handler logs correlate by job. Without a logger the worker
is silent. It never logs your payloads or your API key.
Shutdown grace
When draining, the worker stops claiming new jobs and waits up to
shutdown_grace_s: for in-flight jobs to finish. Jobs still running when the
grace expires are not force-killed (that could corrupt a connection mid-call) —
they are left to the server, which re-delivers a job whose worker disappears.
Keep shutdown_grace_s: under your platform's own termination grace so jobs
drain before the process is hard-killed.