Interface: ReplayWorkerOptions
worker.ReplayWorkerOptions
WorkerOptions with inapplicable-to-replay fields removed.
Hierarchyâ
Omit<WorkerOptions,"connection"|"namespace"|"taskQueue"|"activities"|"maxConcurrentActivityTaskExecutions"|"maxConcurrentLocalActivityExecutions"|"maxConcurrentWorkflowTaskExecutions"|"maxHeartbeatThrottleInterval"|"defaultHeartbeatThrottleInterval"|"debugMode"|"enableNonLocalActivities"|"maxActivitiesPerSecond"|"maxTaskQueueActivitiesPerSecond"|"stickyQueueScheduleToStartTimeout"|"maxCachedWorkflows"|"useVersioning">âŗ
ReplayWorkerOptions
Propertiesâ
buildIdâ
âĸ Optional buildId: string
A string that should be unique to the exact worker code/binary being executed.
This is used to uniquely identify the worker's code for a handful of purposes, including the
worker versioning feature if you have opted into that with
useVersioning. It will also populate the binaryChecksum field
on older servers.
âšī¸ Required if useVersioning is true.
Default
@temporalio/worker package name and version + checksum of workflow bundle's code
Inherited fromâ
Omit.buildId
bundlerOptionsâ
âĸ Optional bundlerOptions: Object
Type declarationâ
| Name | Type | Description |
|---|---|---|
ignoreModules? | string[] | List of modules to be excluded from the Workflows bundle. Use this option when your Workflow code references an import that cannot be used in isolation, e.g. a Node.js built-in module. Modules listed here MUST not be used at runtime. > NOTE: This is an advanced option that should be used with care. |
webpackConfigHook? | (config: Configuration) => Configuration | Before Workflow code is bundled with Webpack, webpackConfigHook is called with the Webpack configuration object so you can modify it. |
Inherited fromâ
Omit.bundlerOptions
dataConverterâ
âĸ Optional dataConverter: DataConverter
Provide a custom DataConverter.
Inherited fromâ
Omit.dataConverter
enableSDKTracingâ
âĸ Optional enableSDKTracing: boolean
Enable opentelemetry tracing of SDK internals like polling, processing and completing tasks.
Useful for debugging issues with the SDK itself.
For completeness the Rust Core also generates opentelemetry spans which connect to the Worker's spans. Configure CoreOptions.telemetryOptions to enable tracing in Core.
Default
false
Inherited fromâ
Omit.enableSDKTracing
identityâ
âĸ Optional identity: string
A human-readable string that can identify your worker
Note that in most production environments, the identity value set by default may be unhelpful for traceability
purposes. It is highly recommended that you set this value to something that will allow you to efficiently identify
that particular Worker container/process/logs in your infrastructure (ex: the task ID allocated to this container
by your orchestrator).
Default
${process.pid}@${os.hostname()}
Inherited fromâ
Omit.identity
interceptorsâ
âĸ Optional interceptors: WorkerInterceptors
A mapping of interceptor type to a list of factories or module paths.
By default, ActivityInboundLogInterceptor and WorkflowInboundLogInterceptor are installed. If you wish to customize the interceptors while keeping the defaults, use appendDefaultInterceptors.
When using workflowBundle, these Workflow interceptors (WorkerInterceptors.workflowModules) are not used.
Instead, provide them via workflowInterceptorModules when calling bundleWorkflowCode.
Inherited fromâ
Omit.interceptors
maxConcurrentActivityTaskPollsâ
âĸ Optional maxConcurrentActivityTaskPolls: number
Maximum number of Activity tasks to poll concurrently.
Increase this setting if your Worker is failing to fill in all of its
maxConcurrentActivityTaskExecutions slots despite a backlog of Activity
Tasks in the Task Queue (ie. due to network latency). Can't be higher than
maxConcurrentActivityTaskExecutions.
Default
min(2, maxConcurrentActivityTaskExecutions)
Inherited fromâ
Omit.maxConcurrentActivityTaskPolls
maxConcurrentWorkflowTaskPollsâ
âĸ Optional maxConcurrentWorkflowTaskPolls: number
Maximum number of Workflow Tasks to poll concurrently.
In general, a Workflow Worker's performance is mostly network bound (due to communication latency with the Temporal server). Polling multiple Workflow Tasks concurrently helps compensate for this latency, by ensuring that the Worker is not starved waiting for the server to return new Workflow Tasks to execute.
This setting is highly related with maxConcurrentWorkflowTaskExecutions. In various
performance tests, we generally got optimal performance by setting this value to about half of
maxConcurrentWorkflowTaskExecutions. Your millage may vary.
Setting this value higher than needed may have negative impact on the server's performance. Consequently, the server may impose a limit on the total number of concurrent Workflow Task pollers.
General guidelines:
- By default, set this value to half of
maxConcurrentWorkflowTaskExecutions. - Increase if actual number of Workflow Tasks being processed concurrently is lower than
maxConcurrentWorkflowTaskExecutionsdespite a backlog of Workflow Tasks in the Task Queue. - Keep this value low for Task Queues which have very few concurrent Workflow Executions.
Can't be higher than maxConcurrentWorkflowTaskExecutions, and can't be lower than 2.
Default
min(10, maxConcurrentWorkflowTaskExecutions)
Inherited fromâ
Omit.maxConcurrentWorkflowTaskPolls
replayNameâ
âĸ Optional replayName: string
A optional name for this replay worker. It will be combined with an incremental ID to form a unique task queue for the replay worker.
Default
"fake_replay_queue"
reuseV8Contextâ
âĸ Optional reuseV8Context: boolean
Toggle whether to reuse a single V8 context for the workflow sandbox.
Context reuse significantly decreases the amount of resources taken up by workflows. From running basic stress tests we've observed 2/3 reduction in memory usage and 1/3 to 1/2 in CPU usage with this feature turned on.
Note that we plan to turn this option on by default starting with 1.9.0.
Default
false (will change in the future)
Inherited fromâ
Omit.reuseV8Context
showStackTraceSourcesâ
âĸ Optional showStackTraceSources: boolean
Whether or not to send the sources in enhanced stack trace query responses
Default
false
Inherited fromâ
Omit.showStackTraceSources
shutdownForceTimeâ
âĸ Optional shutdownForceTime: Duration
Time to wait before giving up on graceful shutdown and forcefully terminating the worker.
After this duration, the worker will throw GracefulShutdownPeriodExpiredError and any running activities and workflows will not be cleaned up. It is recommended to exit the process after this error is thrown.
Use this option if you must guarantee that the worker eventually shuts down.
Format
number of milliseconds or ms-formatted string
Inherited fromâ
Omit.shutdownForceTime
shutdownGraceTimeâ
âĸ Optional shutdownGraceTime: Duration
Time to wait for pending tasks to drain after shutdown was requested.
In-flight activities will be cancelled after this period and their current attempt will be resolved as failed if
they confirm cancellation (by throwing a CancelledFailure or AbortError).
Format
number of milliseconds or ms-formatted string
Default
0
Inherited fromâ
Omit.shutdownGraceTime
sinksâ
âĸ Optional sinks: InjectedSinks<any>
Registration of a SinkFunction, including per-sink-function options.
Sinks are a mechanism for exporting data out of the Workflow sandbox. They are typically used to implement in-workflow observability mechanisms, such as logs, metrics and traces.
To prevent non-determinism issues, sink functions may not have any observable side effect on the execution of a workflow. In particular, sink functions may not return values to the workflow, nor throw errors to the workflow (an exception thrown from a sink function simply get logged to the Runtime's logger).
For similar reasons, sink functions are not executed immediately when a call is made from workflow code. Instead, calls are buffered until the end of the workflow activation; they get executed right before returning a completion response to Core SDK. Note that the time it takes to execute sink functions delays sending a completion response to the server, and may therefore induce Workflow Task Timeout errors. Sink functions should thus be kept as fast as possible.
Sink functions are always invoked in the order that calls were maded in workflow code. Note however that async sink functions are not awaited individually. Consequently, sink functions that internally perform async operations may end up executing concurrently.
Please note that sink functions only provide best-effort delivery semantics, which is generally
suitable for log messages and general metrics collection. However, in various situations, a sink
function call may execute more than once even though the sink function is configured with
callInReplay: false. Similarly, sink function execution errors only results in log messages,
and are therefore likely to go unnoticed. For use cases that require at-least-once execution
guarantees, please consider using local activities instead. For use cases that require
exactly-once or at-most-once execution guarantees, please consider using regular activities.
The SDK itself may register sinks functions required to support workflow features. At the moment, the only such
sink is 'defaultWorkerLogger', which is used by the workflow context logger (ie. workflow.log.info() and
friends); other sinks may be added in the future. You may override these default sinks by explicitely registering
sinks with the same name.
Inherited fromâ
Omit.sinks
workflowBundleâ
âĸ Optional workflowBundle: WorkflowBundleOption
Use a pre-built bundle for Workflow code. Use bundleWorkflowCode to generate the bundle. The version of
@temporalio/worker used when calling bundleWorkflowCode must be the exact same version used when calling
Worker.create.
This is the recommended way to deploy Workers to production.
See https://docs.temporal.io/typescript/production-deploy#pre-build-code for more information.
When using this option, workflowsPath, bundlerOptions and any Workflow interceptors modules provided in * interceptors are not used. To use workflow interceptors, pass them via workflowInterceptorModules when calling bundleWorkflowCode.
Inherited fromâ
Omit.workflowBundle
workflowThreadPoolSizeâ
âĸ Optional workflowThreadPoolSize: number
Controls the number of threads to be created for executing Workflow Tasks.
Adjusting this value is generally not useful, as a Workflow Worker's performance is mostly network bound (due to
communication latency with the Temporal server) rather than CPU bound. Increasing this may however help reduce
the probability of Workflow Tasks Timeouts in some particular situations, for example when replaying many very
large Workflow Histories at the same time. It may also make sense to tune this value if
maxConcurrentWorkflowTaskExecutions and maxConcurrentWorkflowTaskPolls are increased enough so that the Worker
doesn't get starved waiting for Workflow Tasks to execute.
There is no major downside in setting this value _slightly) higher than needed; consider however that there is a per-thread cost, both in terms of memory footprint and CPU usage, so arbitrarily setting some high number is definitely not advisable.
Threading modelâ
All interactions with Core SDK (including polling for Workflow Activations and sending back completion results) happens on the main thread. The main thread then dispatches Workflow Activations to some worker thread, which create and maintain a per-Workflow isolated execution environments (aka. the Workflow Sandbox), implemented as VM contexts.
When reuseV8Context is disabled, a new VM context is created for each Workflow handled by the Worker.
Creating a new VM context is a relatively lengthy operation which blocks the Node.js event loop. Using multiple
threads helps compensate the impact of this operation on the Worker's performance.
When reuseV8Context is enabled, a single VM context is created for each worker thread, then reused for every
Workflows handled by that thread (per-Workflow objects get shuffled in and out of that context on every Workflow
Task). Consequently, there is generally no advantage in using multiple threads when reuseV8Context is enabled.
If more than one thread is used, Workflows will be load-balanced evenly between worker threads on the first Activation of a Workflow Execution, based on the number of Workflows currently owned by each worker thread; futher Activations of that Workflow Execution will then be handled by the same thread, until the Workflow Execution gets evicted from cache.
Default
1 if 'reuseV8Context' is enabled; 2 otherwise. Ignored if debugMode is enabled.
Inherited fromâ
Omit.workflowThreadPoolSize
workflowsPathâ
âĸ Optional workflowsPath: string
Path to look up workflows in, any function exported in this path will be registered as a Workflows in this Worker.
If this option is provided to create, Webpack compliation will be triggered.
This option is typically used for local development, for production it's preferred to pre-build the Workflow bundle and pass that to create via the workflowBundle option.
See https://docs.temporal.io/typescript/production-deploy#pre-build-code for more information.
Inherited fromâ
Omit.workflowsPath