Get desktop application:
View/edit binary Protocol Buffers messages
Internal structure used to create worker stack traces with references to code.
Information pertaining to the SDK that the trace has been captured from.
Mapping of file path to file contents.
Collection of stacks captured.
Used in: ,
What this Marker represents. The variant determines whether the Marker was created explicitly by user code (label) or implicitly by the SDK on inbound signals/events (inbound_event) or update handlers (inbound_update).
The event ID of an event in the present workflow that triggered implicit creation of this group Marker. The target event's type must be one of the following: - `WORKFLOW_EXECUTION_STARTED` - `WORKFLOW_EXECUTION_SIGNALED`
Used in:
The identifier of an inbound Update (request.meta.update_id) whose handler triggered implicit creation of this group Marker. Used in place of `inbound_event_id` for Updates because the event ID of the UpdateAccepted history event is not known until the Workflow Task is completed and recorded by the server, which may be too late.
Used in:
A user-defined short-form string value to be used as the group's label.
Used in:
Opaque identifier assigned by the SDK.
This payload should be a "json/plain"-encoded payload that is a single JSON string for use in user interfaces. User interface formatting may not apply to this text when used in "label" situations. The payload data section is limited to 400 bytes by default. Payload only needs to be set on the first use of a given Marker ID; further references to an existing Marker ID reuse existing attributes of the referenced Marker -- i.e. further label payloads are ignored. Note that it is valid to have distinct Markers (i.e. distinct Marker IDs) in a given workflow execution that carry the same label, provided that they have the distinct ID.
ExternalStorageReference identifies a payload stored in an external storage system. It is used as a claim-check token, allowing the actual payload data to be retrieved from the named driver using the provided claim data.
The name of the storage driver responsible for retrieving the payload.
Driver-specific key-value pairs that identify and provide access to the stored payload.
Collection of FileLocation messages from a single stack.
Used in:
Collection of `FileLocation`s, each for a stack frame that comprise a stack trace.
More specific location details of a file: its path, precise line and column numbers if applicable, and function name if available. In essence, a pointer to a location in a file
Used in:
Path to source file (absolute or relative). If the paths are relative, ensure that they are all relative to the same root.
Optional; If possible, SDK should send this -- this is required for displaying the code location. If not provided, set to -1.
Optional; if possible, SDK should send this. If not provided, set to -1.
Function name this line belongs to, if applicable. Used for falling back to stack trace view.
Flag to communicate whether a location should be hidden by default in the stack view.
"Slice" of a file starting at line_offset -- a line offset and code fragment corresponding to the worker's stack.
Used in:
Only used (possibly) to trim the file without breaking syntax highlighting. This is not optional, unlike the `line` property of a `StackTraceFileLocation`. (-- api-linter: core::0141::forbidden-types=disabled aip.dev/not-precedent: These really shouldn't have negative values. --)
Slice of a file with the respective OS-specific line terminator.
Information pertaining to the SDK that the trace has been captured from. (-- api-linter: core::0123::resource-annotation=disabled aip.dev/not-precedent: Naming SDK version is optional. --)
Used in:
Name of the SDK
Version string of the SDK
Information a user can set, often for use by user interfaces.
Used in: , , , , , , , , ,
Short-form text that provides a summary. This payload should be a "json/plain"-encoded payload that is a single JSON string for use in user interfaces. User interface formatting may not apply to this text when used in "title" situations. The payload data section is limited to 400 bytes by default.
Long-form text that provides details. This payload should be a "json/plain"-encoded payload that is a single JSON string for use in user interfaces. User interface formatting may apply to this text in common use. The payload data section is limited to 20000 bytes by default.
Used in: , ,
Used in:
At least this many poll calls will always be attempted (assuming slots are available). Cannot be zero.
At most this many poll calls will ever be open at once. Must be >= `minimum`.
This many polls will be attempted initially before scaling kicks in. Must be between `minimum` and `maximum`.
Used in:
(-- api-linter: core::0203::optional=disabled --)
Used in:
A name scoped by the task queue that maps to this workflow definition. If missing, this workflow is a dynamic workflow.
Query definitions, sorted by name.
Signal definitions, sorted by name.
Update definitions, sorted by name.
(-- api-linter: core::0123::resource-annotation=disabled aip.dev/not-precedent: The `name` field is optional. --) (-- api-linter: core::0203::optional=disabled --)
Used in:
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.
The name of the query to retrieve this information is `__temporal_workflow_metadata`.
Metadata provided at declaration or creation time.
Current long-form details of the workflow's state. This is used by user interfaces to show long-form text. This text may be formatted by the user interface.
Used in: ,
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).