For the complete documentation index, see llms.txt.
Skip to main content
Version: 8.10

Interface: ThreadedJobWorkerConfig<In, Out, Headers>

Configuration for a threaded job worker. Same as JobWorkerConfig but replaces jobHandler with handlerModule.

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

handlerModule​

handlerModule: string;

Absolute or relative path to a JS/TS module that exports a default handler function. The function signature must be: (job, client) => Promise<JobActionReceipt>

inputSchema?​

optional inputSchema?: In;

Zod schema for variables in the activated job

jobTimeoutMs?​

optional jobTimeoutMs?: number;

Job activation timeout in ms — default 60000. Overridden by CAMUNDA_WORKER_TIMEOUT env var.

jobType​

jobType: string;

Zeebe job type

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.

threadPoolSize?​

optional threadPoolSize?: number;

Number of threads in the shared pool (used only when the pool is first created; subsequent workers share the existing pool). Default: number of CPU cores available to the process.

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. See JobWorkerConfig.withLease.

Note: the threaded jobHandler intentionally keeps the base job shape (jobLeaseToken remains optional/nullable); the token is threaded back into fenced commands automatically, so handlers do not read it directly.

workerName?​

optional workerName?: string;

Optional explicit name