Interface: JobWorkerConfig<In, Out, Headers>
Type Parameters
In
In extends z.ZodTypeAny = any
Out
Out extends z.ZodTypeAny = any
Headers
Headers extends z.ZodTypeAny = any
Properties
autoStart?
optional autoStart?: boolean;
Immediately start polling for work - default true
customHeadersSchema?
optional customHeadersSchema?: Headers;
Zod schema for custom headers in the activated job
fetchVariables?
optional fetchVariables?: In extends ZodTypeAny<unknown, unknown, $ZodTypeInternals<unknown, unknown>> ? Extract<keyof output<In>, string>[] : string[];
Optional list of variable names to fetch during activation
inputSchema?
optional inputSchema?: In;
Zod schema for variables in the activated job
jobHandler
jobHandler: (job) => "JOB_ACTION_RECEIPT" | Promise<"JOB_ACTION_RECEIPT">;
Parameters
job
Job<In, Headers>
Returns
"JOB_ACTION_RECEIPT" | Promise<"JOB_ACTION_RECEIPT">
jobTimeoutMs?
optional jobTimeoutMs?: number;
Job activation timeout in ms — default 60000. Overridden by CAMUNDA_WORKER_TIMEOUT env var.
jobType
jobType: string;
Zeebe job type
maxBackoffTimeMs?
optional maxBackoffTimeMs?: number;
Deprecated
Not used; pacing handled by long polling + client backpressure. Present only for migration compatibility.
maxParallelJobs?
optional maxParallelJobs?: number;
Concurrency limit — default 10. Overridden by CAMUNDA_WORKER_MAX_CONCURRENT_JOBS env var.
outputSchema?
optional outputSchema?: Out;
Zod schema for variables in the complete command
pollBackoffMaxMs?
optional pollBackoffMaxMs?: number;
Ceiling (ms) of the between-failed-poll exponential backoff. Default 30000.
pollBackoffMinMs?
optional pollBackoffMinMs?: number;
Floor (ms) of the exponential backoff applied between failed activation
requests (connection refused, connect timeout, broker restart, LAN blip …).
The first retry waits ≈ this/2–this ms; subsequent consecutive failures
double the window up to pollBackoffMaxMs, with jitter, and reset to
zero on the first successful poll. Default 1000. Set to 0 to disable backoff (failed polls then fall back to pollIntervalMs rather than retrying immediately).
pollIntervalMs?
optional pollIntervalMs?: number;
Backoff between polls - default 1ms
pollTimeoutMs?
optional pollTimeoutMs?: number;
The request will be completed when at least one job is activated or after the requestTimeout. If the requestTimeout = 0, the request will be completed after a default configured timeout in the broker. To immediately complete the request when no job is activated set the requestTimeout to a negative value
startupJitterMaxSeconds?
optional startupJitterMaxSeconds?: number;
Maximum random delay (in seconds) before the worker starts polling.
When multiple application instances restart simultaneously, this spreads out
initial activation requests to avoid saturating the server.
0 (the default) means no delay.
validateSchemas?
optional validateSchemas?: boolean;
Validate any provided input, output, customheader schema default: false
withLease?
optional withLease?: boolean;
Activate jobs with a lease — default false.
When true, each activated job is assigned a distinct, opaque lease token
(ActivatedJobResult.jobLeaseToken) that is automatically threaded back into the
fenced complete / fail / error commands. The lease fences those commands
against a superseded activation of the same job (e.g. after a timeout and
re-activation by another worker): a command carrying a stale token is rejected
rather than racing the newer activation. Once a job type is leased, it is served
only to leasing workers of that type, so a homogeneous fleet per job type is
recommended.
Note: the marker-derived non-null jobLeaseToken projection applies to the
direct activateJobs client call; a worker jobHandler intentionally keeps
the base Job<...> shape (jobLeaseToken remains optional/nullable) because the
token is threaded back into fenced commands automatically — handlers do not
need to read it.
workerName?
optional workerName?: string;
Optional explicit name