Protocol Documentation

Current state of the requested namespace.

Allowed namespace states for requested operation. For example NAMESPACE_STATE_DELETED is forbidden for most operations but allowed for DescribeNamespace.

The current default compatible build ID which will receive tasks

WorkflowId and RunId of the Temporal system workflow performing the underlying operation. Looking up the info of the system workflow run may help identify the issue causing the failure.

Serialized error returned by the system workflow performing the underlying operation.

If `query` is not grouping by any field, the count is an approximate number of workflows that matches the query. If `query` is grouping by a field, the count is simply the sum of the counts of the groups returned in the response. This number can be smaller than the total number of workflows matching the query.

`groups` contains the groups if the request is grouping by a field. The list might not be complete, and the counts of each group is approximate.

The namespace the schedule should be created in.

The id of the new schedule.

The schedule spec, policies, action, and initial state.

Optional initial patch (e.g. to run the action once immediately).

The identity of the client who initiated this request.

A unique identifier for this create request for idempotence. Typically UUIDv4.

Memo and search attributes to attach to the schedule itself.

The namespace of the schedule to delete.

The id of the schedule to delete.

The identity of the client who initiated this request.

Workflow Execution to delete. If run_id is not specified, the latest one is used.

Namespace that contains the batch operation

Batch job id

Batch operation type

Batch job ID

Batch operation state

Batch operation start time

Batch operation close time

Total operation count

Complete operation count

Failure operation count

Identity indicates the operator identity

Reason indicates the reason to stop a operation

Contains the historical state of failover_versions for the cluster, truncated to contain only the last N states to ensure that the list does not grow unbounded.

The namespace of the schedule to describe.

The id of the schedule to describe.

The complete current schedule details. This may not match the schedule as created because: - some types of schedule specs may get compiled into others (e.g. CronString into StructuredCalendarSpec) - some unspecified fields may be replaced by defaults - some fields in the state are modified automatically - the schedule may have been modified by UpdateSchedule or PatchSchedule

Extra schedule state info.

The memo and search attributes that the schedule was created with.

This value can be passed back to UpdateSchedule to ensure that the schedule was not modified between a Describe and an Update, which could lead to lost updates and other confusion.

If unspecified (TASK_QUEUE_TYPE_UNSPECIFIED), then default value (TASK_QUEUE_TYPE_WORKFLOW) will be used.

Key is client name i.e "temporal-go", "temporal-java", or "temporal-cli". Value is ranges of supported versions of this client i.e ">1.1.1 <=1.4.0 || ^5.0.0".

Version of the server.

All capabilities the system supports.

True if signal and query headers are supported.

True if internal errors are differentiated from other types of errors for purposes of retrying non-internal errors. When unset/false, clients retry all failures. When true, clients should only retry non-internal errors.

True if RespondActivityTaskFailed API supports including heartbeat details

Supports scheduled workflow features.

True if server uses protos that include temporal.api.failure.v1.Failure.encoded_attributes

True if server supports dispatching Workflow and Activity tasks based on a worker's build_id (see: https://github.com/temporalio/proposals/blob/a123af3b559f43db16ea6dd31870bfb754c4dc5e/versioning/worker-versions.md)

True if server supports upserting workflow memo

True if server supports eager workflow task dispatching for the StartWorkflowExecution API

True if the server knows about the sdk metadata field on WFT completions and will record it in history

True if the server supports count group by execution status (-- api-linter: core::0140::prepositions=disabled --)

Must be set, the task queue to interrogate about worker id compatibility.

Limits how many compatible sets will be returned. Specify 1 to only return the current default major version set. 0 returns all sets.

Major version sets, in order from oldest to newest. The last element of the list will always be the current default major version. IE: New workflows will target the most recent version in that version set. There may be fewer sets returned than exist, if the request chose to limit this response.

Build ids to retrieve reachability for. An empty string will be interpreted as an unversioned worker. The number of build ids that can be queried in a single API call is limited. Open source users can adjust this limit by setting the server's dynamic config value for `limit.reachabilityQueryBuildIds` with the caveat that this call can strain the visibility store.

Task queues to retrieve reachability for. Leave this empty to query for all task queues associated with given build ids in the namespace. Must specify at least one task queue if querying for an unversioned worker. The number of task queues that the server will fetch reachability information for is limited. See the `GetWorkerTaskReachabilityResponse` documentation for more information.

Type of reachability to query for. `TASK_REACHABILITY_NEW_WORKFLOWS` is always returned in the response. Use `TASK_REACHABILITY_EXISTING_WORKFLOWS` if your application needs to respond to queries on closed workflows. Otherwise, use `TASK_REACHABILITY_OPEN_WORKFLOWS`. Default is `TASK_REACHABILITY_EXISTING_WORKFLOWS` if left unspecified. See the TaskReachability docstring for information about each enum variant.

Task reachability, broken down by build id and then task queue. When requesting a large number of task queues or all task queues associated with the given build ids in a namespace, all task queues will be listed in the response but some of them may not contain reachability information due to a server enforced limit. When reaching the limit, task queues that reachability information could not be retrieved for will be marked with a single TASK_REACHABILITY_UNSPECIFIED entry. The caller may issue another call to get the reachability for those task queues. Open source users can adjust this limit by setting the server's dynamic config value for `limit.reachabilityTaskQueueScan` with the caveat that this call can strain the visibility store.

If a `GetWorkflowExecutionHistoryResponse` or a `PollWorkflowTaskQueueResponse` had one of these, it should be passed here to fetch the next page.

If set to true, the RPC call will not resolve until there is a new event which matches the `history_event_filter_type`, or a timeout is hit.

Filter returned events such that they match the specified filter type. Default: HISTORY_EVENT_FILTER_TYPE_ALL_EVENT.

Raw history is an alternate representation of history that may be returned if configured on the frontend. This is not supported by all SDKs. Either this or `history` will be set.

Will be set if there are more history events than were included in this response

Will be set if there are more history events than were included in this response

Namespace that contains the batch operation

List page size

Next page token

BatchOperationInfo contains the basic info about batch operation

The namespace of the schedule to query.

The id of the schedule to query.

Time range to query.

The namespace to list schedules in.

How many to return at once.

Token to get the next page of results.

The namespace of the schedule to patch.

The id of the schedule to patch.

The identity of the client who initiated this request.

A unique identifier for this update request for idempotence. Typically UUIDv4.

The identity of the worker/client

Information about this worker's build identifier and if it is choosing to use the versioning feature. See the `WorkerVersionCapabilities` docstring for more.

A unique identifier for this task

The namespace the workflow which requested this activity lives in

Type of the requesting workflow

Execution info of the requesting workflow

The autogenerated or user specified identifier of this activity. Can be used to complete the activity via `RespondActivityTaskCompletedById`. May be re-used as long as the last usage has resolved, but unique IDs for every activity invocation is a good idea.

Headers specified by the scheduling workflow. Commonly used to propagate contextual info from the workflow to its activities. For example, tracing contexts.

Arguments to the activity invocation

Details of the last heartbeat that was recorded for this activity as of the time this task was delivered.

When was this task first scheduled

When was this task attempt scheduled

When was this task started (this attempt)

Starting at 1, the number of attempts to perform this activity

First scheduled -> final result reported timeout (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --)

Current attempt start -> final result reported timeout (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: "to" is used to indicate interval. --)

Window within which the activity must report a heartbeat, or be timed out.

This is the retry policy the service uses which may be different from the one provided (or not) during activity scheduling. The service can override the provided one if some values are not specified or exceed configured system limits.

The identity of the client who initiated this request.

Information about this worker's build identifier and if it is choosing to use the versioning feature. See the `WorkerVersionCapabilities` docstring for more.

An opaque unique identifier for this task for correlating a completion request the embedded request.

Embedded request as translated from the incoming frontend request.

The namespace of the workflow execution to which the update was originally issued.

The update reference returned in the initial UpdateWorkflowExecutionResponse

The identity of the worker/client who is polling this update outcome

Describes when this poll request should return a response. Omit to request a non-blocking poll.

The outcome of the update if and only if the update has completed. If this response is being returned before the update has completed (e.g. due to the specification of a wait policy that only waits on UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_ACCEPTED) then this field will not be set.

The most advanced lifecycle stage that the Update is known to have reached, where lifecycle stages are ordered UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_UNSPECIFIED < UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_ADMITTED < UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_ACCEPTED < UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_COMPLETED. UNSPECIFIED will be returned if and only if the server's maximum wait time was reached before the Update reached the stage specified in the request WaitPolicy, and before the context deadline expired; clients may may then retry the call as needed.

Sufficient information to address this update.

The identity of the worker/client who is polling this task queue

DEPRECATED since 1.21 - use `worker_version_capabilities` instead. Each worker process should provide an ID unique to the specific set of code it is running "checksum" in this field name isn't very accurate, it should be though of as an id.

Information about this worker's build identifier and if it is choosing to use the versioning feature. See the `WorkerVersionCapabilities` docstring for more.

A unique identifier for this task

The last workflow task started event which was processed by some worker for this execution. Will be zero if no task has ever started.

The id of the most recent workflow task started event, which will have been generated as a result of this poll request being served. Will be zero if the task does not contain any events which would advance history (no new WFT started). Currently this can happen for queries.

Starting at 1, the number of attempts to complete this task by any worker.

A hint that there are more tasks already present in this task queue. Can be used to prioritize draining a sticky queue before polling from a normal queue.

The history for this workflow, which will either be complete or partial. Partial histories are sent to workers who have signaled that they are using a sticky queue when completing a workflow task.

Will be set if there are more history events than were included in this response. Such events should be fetched via `GetWorkflowExecutionHistory`.

Legacy queries appear in this field. The query must be responded to via `RespondQueryTaskCompleted`. If the workflow is already closed (queries are permitted on closed workflows) then the `history` field will be populated with the entire history. It may also be populated if this task originates on a non-sticky queue.

The task queue this task originated from, which will always be the original non-sticky name for the queue, even if this response came from polling a sticky queue.

When this task was scheduled by the server

When the current workflow task started event was generated, meaning the current attempt.

Queries that should be executed after applying the history in this task. Responses should be attached to `RespondWorkflowTaskCompletedRequest::query_results`

Protocol messages piggybacking on a WFT as a transport

QueryRejectCondition can used to reject the query if workflow state does not satisfy condition. Default: QUERY_REJECT_CONDITION_NONE.

Namespace of the workflow which scheduled this activity

Id of the workflow which scheduled this activity

Run Id of the workflow which scheduled this activity

Id of the activity we're heartbeating

Arbitrary data, of which the most recent call is kept, to store for this activity

The identity of the worker/client

Will be set to true if the activity has been asked to cancel itself. The SDK should then notify the activity of cancellation if it is still running.

The task token as received in `PollActivityTaskQueueResponse`

Arbitrary data, of which the most recent call is kept, to store for this activity

The identity of the worker/client

Will be set to true if the activity has been asked to cancel itself. The SDK should then notify the activity of cancellation if it is still running.

A key-value map for any customized purpose.

If unspecified (ARCHIVAL_STATE_UNSPECIFIED) then default server configuration is used.

If unspecified (ARCHIVAL_STATE_UNSPECIFIED) then default server configuration is used.

The identity of the worker/client

Used to de-dupe cancellation requests

If set, this call will error if the most recent (if no run id is set on `workflow_execution`), or specified (if it is) workflow execution is not part of the same execution chain as this id.

Reason for requesting the cancellation

The id of a `WORKFLOW_TASK_COMPLETED`,`WORKFLOW_TASK_TIMED_OUT`, `WORKFLOW_TASK_FAILED`, or `WORKFLOW_TASK_STARTED` event to reset to.

Used to de-dupe reset requests

Event types to be reapplied (deprecated) Default: RESET_REAPPLY_TYPE_ALL_ELIGIBLE

Event types not to be reapplied

Namespace of the workflow which scheduled this activity

Id of the workflow which scheduled this activity

Run Id of the workflow which scheduled this activity

Id of the activity to confirm is cancelled

Serialized additional information to attach to the cancellation

The identity of the worker/client

The task token as received in `PollActivityTaskQueueResponse`

Serialized additional information to attach to the cancellation

The identity of the worker/client

Version info of the worker who processed this task. This message's `build_id` field should always be set by SDKs. Workers opting into versioning will also set the `use_versioning` field to true. See message docstrings for more.

Namespace of the workflow which scheduled this activity

Id of the workflow which scheduled this activity

Run Id of the workflow which scheduled this activity

Id of the activity to complete

The serialized result of activity execution

The identity of the worker/client

The task token as received in `PollActivityTaskQueueResponse`

The result of successfully executing the activity

The identity of the worker/client

Version info of the worker who processed this task. This message's `build_id` field should always be set by SDKs. Workers opting into versioning will also set the `use_versioning` field to true. See message docstrings for more.

Namespace of the workflow which scheduled this activity

Id of the workflow which scheduled this activity

Run Id of the workflow which scheduled this activity

Id of the activity to fail

Detailed failure information

The identity of the worker/client

Additional details to be stored as last activity heartbeat

Server validation failures could include last_heartbeat_details payload is too large, request failure is too large

The task token as received in `PollActivityTaskQueueResponse`

Detailed failure information

The identity of the worker/client

Additional details to be stored as last activity heartbeat

Version info of the worker who processed this task. This message's `build_id` field should always be set by SDKs. Workers opting into versioning will also set the `use_versioning` field to true. See message docstrings for more.

Server validation failures could include last_heartbeat_details payload is too large, request failure is too large

The identity of the client who initiated this request.

A unique identifier for this task as received via a poll response.

Embedded response to be translated into a frontend response.

The identity of the client who initiated this request.

A unique identifier for this task.

The error the handler failed with.

The task token as received in `PollWorkflowTaskQueueResponse`

A list of commands generated when driving the workflow code in response to the new task

The identity of the worker/client

May be set by workers to indicate that the worker desires future tasks to be provided with incremental history on a sticky queue.

If set, the worker wishes to immediately receive the next workflow task as a response to this completion. This can save on polling round-trips.

Can be used to *force* creation of a new workflow task, even if no commands have resolved or one would not otherwise have been generated. This is used when the worker knows it is doing something useful, but cannot complete it within the workflow task timeout. Local activities which run for longer than the task timeout being the prime example.

DEPRECATED since 1.21 - use `worker_version_stamp` instead. Worker process' unique binary id

Responses to the `queries` field in the task being responded to

Version info of the worker who processed this task. This message's `build_id` field should always be set by SDKs. Workers opting into versioning will also set the `use_versioning` field to true. See message docstrings for more.

Protocol messages piggybacking on a WFT as a transport

Data the SDK wishes to record for itself, but server need not interpret, and does not directly impact workflow state.

Local usage data collected for metering

See `RespondWorkflowTaskCompletedResponse::return_new_workflow_task`

See `ScheduleActivityTaskCommandAttributes::request_start`

The task token as received in `PollWorkflowTaskQueueResponse`

Why did the task fail? It's important to note that many of the variants in this enum cannot apply to worker responses. See the type's doc for more.

Failure details

The identity of the worker/client

DEPRECATED since 1.21 - use `worker_version_stamp` instead. Worker process' unique binary id

Protocol messages piggybacking on a WFT as a transport

Version info of the worker who processed this task. This message's `build_id` field should always be set by SDKs. Workers opting into versioning will also set the `use_versioning` field to true. See message docstrings for more.

The task queue to start this workflow on, if it will be started

Serialized arguments to the workflow. These are passed as arguments to the workflow function.

Total workflow execution timeout including retries and continue as new

Timeout of a single workflow run

Timeout of a single workflow task

The identity of the worker/client

Used to de-dupe signal w/ start requests

Defines whether to allow re-using the workflow id from a previously *closed* workflow. The default policy is WORKFLOW_ID_REUSE_POLICY_ALLOW_DUPLICATE. See `workflow_id_reuse_policy` for handling a workflow id duplication with a *running* workflow.

Defines how to resolve a workflow id conflict with a *running* workflow. The default policy is WORKFLOW_ID_CONFLICT_POLICY_USE_EXISTING. Note that WORKFLOW_ID_CONFLICT_POLICY_FAIL is an invalid option. See `workflow_id_reuse_policy` for handling a workflow id duplication with a *closed* workflow.

The workflow author-defined name of the signal to send to the workflow

Serialized value(s) to provide with the signal

Deprecated

Retry policy for the workflow

See https://docs.temporal.io/docs/content/what-is-a-temporal-cron-job/

Time to wait before dispatching the first workflow task. Cannot be used with `cron_schedule`. Note that the signal will be delivered with the first workflow task. If the workflow gets another SignalWithStartWorkflow before the delay and `skip_generate_workflow_task` is false or not set, a workflow task will be dispatched immediately and the rest of the delay period will be ignored, even if that request also had a delay. Signal via SignalWorkflowExecution will not unblock the workflow.

Indicates that a new workflow task should not be generated when this signal is received.

The run id of the workflow that was started - or just signaled, if it was already running.

If true, a new workflow was started.

The workflow author-defined name of the signal to send to the workflow

Serialized value(s) to provide with the signal

The identity of the worker/client

Used to de-dupe sent signals

Deprecated

Headers that are passed with the signal to the processing workflow. These can include things like auth or tracing tokens.

Indicates that a new workflow task should not be generated when this signal is received.

Namespace that contains the batch operation

Visibility query defines the the group of workflow to apply the batch operation This field and `executions` are mutually exclusive

Job ID defines the unique ID for the batch job

Reason to perform the batch operation

Executions to apply the batch operation This field and `visibility_query` are mutually exclusive

Limit for the number of operations processed per second within this batch. Its purpose is to reduce the stress on the system caused by batch operations, which helps to prevent system overload and minimize potential delays in executing ongoing tasks for user workers. Note that when no explicit limit is provided, the server will operate according to its limit defined by the dynamic configuration key `worker.batcherRPS`. This also applies if the value in this field exceeds the server's configured limit.

Serialized arguments to the workflow. These are passed as arguments to the workflow function.

Total workflow execution timeout including retries and continue as new.

Timeout of a single workflow run.

Timeout of a single workflow task.

The identity of the client who initiated this request

A unique identifier for this start request. Typically UUIDv4.

Defines whether to allow re-using the workflow id from a previously *closed* workflow. The default policy is WORKFLOW_ID_REUSE_POLICY_ALLOW_DUPLICATE. See `workflow_id_conflict_policy` for handling a workflow id duplication with a *running* workflow.

Defines how to resolve a workflow id conflict with a *running* workflow. The default policy is WORKFLOW_ID_CONFLICT_POLICY_FAIL. See `workflow_id_reuse_policy` for handling a workflow id duplication with a *closed* workflow.

The retry policy for the workflow. Will never exceed `workflow_execution_timeout`.

See https://docs.temporal.io/docs/content/what-is-a-temporal-cron-job/

Request to get the first workflow task inline in the response bypassing matching service and worker polling. If set to `true` the caller is expected to have a worker available and capable of processing the task. The returned task will be marked as started and is expected to be completed by the specified `workflow_task_timeout`.

These values will be available as ContinuedFailure and LastCompletionResult in the WorkflowExecutionStarted event and through SDKs. The are currently only used by the server itself (for the schedules feature) and are not intended to be exposed in StartWorkflowExecution.

Time to wait before dispatching the first workflow task. Cannot be used with `cron_schedule`. If the workflow gets a signal before the delay, a workflow task will be dispatched and the rest of the delay will be ignored.

Callbacks to be called by the server when this workflow reaches a terminal state. If the workflow continues-as-new, these callbacks will be carried over to the new execution. Callback addresses must be whitelisted in the server's dynamic configuration.

The run id of the workflow that was started - or used (via WorkflowIdConflictPolicy USE_EXISTING).

If true, a new workflow was started.

When `request_eager_execution` is set on the `StartWorkflowExecutionRequest`, the server - if supported - will return the first workflow task to be eagerly executed. The caller is expected to have a worker available to process the task.

Namespace that contains the batch operation

Batch job id

Reason to stop a batch operation

Identity of the operator

Serialized additional information to attach to the termination event

The identity of the worker/client

If set, this call will error if the most recent (if no run id is set on `workflow_execution`), or specified (if it is) workflow execution is not part of the same execution chain as this id.

promote local namespace to global namespace. Ignored if namespace is already global namespace.

The namespace of the schedule to update.

The id of the schedule to update.

The new schedule. The four main fields of the schedule (spec, action, policies, state) are replaced completely by the values in this message.

This can be the value of conflict_token from a DescribeScheduleResponse, which will cause this request to fail if the schedule has been modified between the Describe and this Update. If missing, the schedule will be updated unconditionally.

The identity of the client who initiated this request.

A unique identifier for this update request for idempotence. Typically UUIDv4.

Must be set, the task queue to apply changes to. Because all workers on a given task queue must have the same set of workflow & activity implementations, there is no reason to specify a task queue type here.

A new build id. This operation will create a new set which will be the new overall default version for the queue, with this id as its only member. This new set is incompatible with all previous sets/versions. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: In makes perfect sense here. --)

Adds a new id to an existing compatible set, see sub-message definition for more.

Promote an existing set to be the current default (if it isn't already) by targeting an existing build id within it. This field's value is the extant build id. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: Names are hard. --)

Promote an existing build id within some set to be the current default for that set. (-- api-linter: core::0140::prepositions=disabled aip.dev/not-precedent: Within makes perfect sense here. --)

Merge two existing sets together, thus declaring all build IDs in both sets compatible with one another. The primary set's default will become the default for the merged set. This is useful if you've accidentally declared a new ID as incompatible you meant to declare as compatible. The unusual case of incomplete replication during failover could also result in a split set, which this operation can repair.

A new id to be added to an existing compatible set.

A build id which must already exist in the version sets known by the task queue. The new id will be stored in the set containing this id, marking it as compatible with the versions within.

When set, establishes the compatible set being targeted as the overall default for the queue. If a different set was the current default, the targeted set will replace it as the new default.

A build ID in the set whose default will become the merged set default

A build ID in the set which will be merged into the primary set

The namespace name of the target workflow

The target workflow id and (optionally) a specific run thereof (-- api-linter: core::0203::optional=disabled aip.dev/not-precedent: false positive triggered by the word "optional" --)

If set, this call will error if the most recent (if no run id is set on `workflow_execution`), or specified (if it is) workflow execution is not part of the same execution chain as this id.

Describes when this request should return - basically whether the update is synchronous, asynchronous, or somewhere in between.

The request information that will be delivered all the way down to the workflow execution.

Enough information for subsequent poll calls if needed. Never null.

The outcome of the update if and only if the workflow execution update has completed. If this response is being returned before the update has completed then this field will not be set.

The most advanced lifecycle stage that the Update is known to have reached, where lifecycle stages are ordered UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_UNSPECIFIED < UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_ADMITTED < UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_ACCEPTED < UPDATE_WORKFLOW_EXECUTION_LIFECYCLE_STAGE_COMPLETED. UNSPECIFIED will be returned if and only if the server's maximum wait time was reached before the Update reached the stage specified in the request WaitPolicy, and before the context deadline expired; clients may may then retry the call as needed.

The workflow-author-defined identifier of the query. Typically a function name.

Serialized arguments that will be provided to the query handler.

Headers that were passed by the caller of the query and copied by temporal server into the workflow task.

Did the query succeed or fail?

Set when the query succeeds with the results

Mutually exclusive with `answer`. Set when the query fails.

Type of operation to cancel.

Operation ID as originally generated by a Handler.

See https://github.com/nexus-rpc/api/blob/main/SPEC.md#predefined-handler-errors.

Data version for this service, incremented for every update issued via the UpdateNexusIncomingService API.

Unique server-generated service ID.

Spec for the service.

The date and time when the service was created. (-- api-linter: core::0142::time-field-names=disabled aip.dev/not-precedent: Not following linter rules. --)

The date and time when the service was last modified. Will not be set if the service has never been modified. (-- api-linter: core::0142::time-field-names=disabled aip.dev/not-precedent: Not following linter rules. --)

Server exposed URL prefix for invocation of operations on this service. This doesn't include the protocol, hostname or port as the server does not know how it should be accessed publicly. The URL is stable in the face of service renames.

Service name, unique for this cluster. Must match `[a-zA-Z_][a-zA-Z0-9_]*`.

Namespace to route requests to.

Task queue to route requests to.

Generic service metadata that is available to the server's authorizer.

Data version for this service, incremented for every mutation.

Name of the service

Spec for the service.

The date and time when the service was created. (-- api-linter: core::0142::time-field-names=disabled aip.dev/not-precedent: Not following linter rules. --)

The date and time when the service was last modified. Will not be set if the service has never been modified. (-- api-linter: core::0142::time-field-names=disabled aip.dev/not-precedent: Not following linter rules. --)

URL to invoke requests.

Headers extracted from the original request in the Temporal frontend. When using Nexus over HTTP, this includes the request's HTTP headers ignoring multiple values.

Type of operation to start.

A request ID that can be used as an idempotentency key.

Callback URL to call upon completion if the started operation is async.

Full request body from the incoming HTTP request.

The operation completed unsuccessfully (failed or canceled).

See https://github.com/nexus-rpc/api/blob/main/SPEC.md#operationinfo.

Internal flags used by the core SDK. SDKs using flags must comply with the following behavior: During replay: * If a flag is not recognized (value is too high or not defined), it must fail the workflow task. * If a flag is recognized, it is stored in a set of used flags for the run. Code checks for that flag during and after this WFT are allowed to assume that the flag is present. * If a code check for a flag does not find the flag in the set of used flags, it must take the branch corresponding to the absence of that flag. During non-replay execution of new WFTs: * The SDK is free to use all flags it knows about. It must record any newly-used (IE: not previously recorded) flags when completing the WFT. SDKs which are too old to even know about this field at all are considered to produce undefined behavior if they replay workflows which used this mechanism. (-- api-linter: core::0141::forbidden-types=disabled aip.dev/not-precedent: These really shouldn't have negative values. --)

Flags used by the SDK lang. No attempt is made to distinguish between different SDK languages here as processing a workflow with a different language than the one which authored it is already undefined behavior. See `core_used_patches` for more. (-- api-linter: core::0141::forbidden-types=disabled aip.dev/not-precedent: These really shouldn't have negative values. --)

Name of the SDK that processed the task. This is usually something like "temporal-go" and is usually the same as client-name gRPC header. This should only be set if its value changed since the last time recorded on the workflow (or be set on the first task). (-- api-linter: core::0122::name-suffix=disabled aip.dev/not-precedent: We're ok with a name suffix here. --)

Version of the SDK that processed the task. This is usually something like "1.20.0" and is usually the same as client-version gRPC header. This should only be set if its value changed since the last time recorded on the workflow (or be set on the first task).

A name scoped by the task queue that maps to this workflow definition. If missing, this workflow is a dynamic workflow.

An optional workflow description provided by the application. By convention, external tools may interpret its first part, i.e., ending with a line break, as a summary of the description.

An optional name for the handler. If missing, it represents a dynamic handler that processes any interactions not handled by others. There is at most one dynamic handler per workflow and interaction kind.

An optional interaction description provided by the application. By convention, external tools may interpret its first part, i.e., ending with a line break, as a summary of the description.

Metadata provided at declaration or creation time.

Information on how this callback should be invoked (e.g. its URL and type).

Trigger for this callback.

The time when the callback was registered.

The number of attempts made to deliver the callback. This number represents a minimum bound since the attempt is incremented after the callback request completes.

The time when the last attempt completed.

The last attempt's failure, if any.

The time when the next attempt is scheduled.

Serialized arguments to the workflow.

Total workflow execution timeout including retries and continue as new.

Timeout of a single workflow run.

Timeout of a single workflow task.

Default: WORKFLOW_ID_REUSE_POLICY_ALLOW_DUPLICATE.

The retry policy for the workflow. Will never exceed `workflow_execution_timeout`.

See https://docs.temporal.io/docs/content/what-is-a-temporal-cron-job/

Default: PARENT_CLOSE_POLICY_TERMINATE.

original_scheduled_time is the scheduled time of the first workflow task during workflow task heartbeat. Heartbeat workflow task is done by RespondWorkflowTaskComplete with ForceCreateNewWorkflowTask == true and no command In this case, OriginalScheduledTime won't change. Then when current time - original_scheduled_time exceeds some threshold, the workflow task will be forced timeout.

Worker build id.

A worker binary version identifier (deprecated).

The first run ID in the execution chain that was touched by this worker build.

Event ID of the first WorkflowTaskCompleted event processed by this worker build.

(-- api-linter: core::0214::resource-expiry=disabled aip.dev/not-precedent: TTL is not defined for ResetPointInfo. --) The time that the run is deleted due to retention.