new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Temporal · all subjects

cli

564 notes in this subject, read out of this brain and free to use. This is page 9 of 10.

TEMPORAL_CLI_ADDRESS environment variable

The TEMPORAL_CLI_ADDRESS environment variable specifies a host and port for the Frontend Service. The default is 127.0.0.1:7233.

TEMPORAL_CLI_AUTHORIZATION_TOKEN environment variable

The TEMPORAL_CLI_AUTHORIZATION_TOKEN environment variable specifies a token to be used by the HTTP Basic Authorization plugin.

TEMPORAL_CLI_AUTH environment variable

The TEMPORAL_CLI_AUTH environment variable specifies the authorization header to be set for a gRPC request.

TEMPORAL_CLI_NAMESPACE environment variable

The TEMPORAL_CLI_NAMESPACE environment variable specifies a Namespace. By setting this variable, you don't need to specify a --namespace modifier in a tctl command. The default Namespace is 'default'.

TEMPORAL_CLI_PLUGIN_DATA_CONVERTER environment variable

The TEMPORAL_CLI_PLUGIN_DATA_CONVERTER environment variable specifies the name of the executable for a custom Data Converter plugin.

TEMPORAL_CLI_PLUGIN_HEADERS_PROVIDER environment variable

The TEMPORAL_CLI_PLUGIN_HEADERS_PROVIDER environment variable specifies the name of the executable for a headers provider plugin.

TEMPORAL_CLI_TLS_CA environment variable

The TEMPORAL_CLI_TLS_CA environment variable specifies the path to a server Certificate Authority (CA) certificate file.

TEMPORAL_CLI_TLS_CERT environment variable

The TEMPORAL_CLI_TLS_CERT environment variable specifies the path to a public X.509 certificate file for mutual TLS authentication.

TEMPORAL_CLI_TLS_DISABLE_HOST_VERIFICATION environment variable

The TEMPORAL_CLI_TLS_DISABLE_HOST_VERIFICATION environment variable disables verification of the server certificate and thus host verification when set.

TEMPORAL_CLI_TLS_KEY environment variable

The TEMPORAL_CLI_TLS_KEY environment variable specifies the path to a private key file for mutual TLS authentication. If you set this variable, you must also set the TEMPORAL_CLI_TLS_CERT variable.

TEMPORAL_CLI_TLS_SERVER_NAME environment variable

The TEMPORAL_CLI_TLS_SERVER_NAME environment variable specifies an override for the name of the target server that is used for TLS host verification. The name must be one of the DNS names listed in the server TLS certificate. Setting this variable also enables host verification.

TEMPORAL_CONTEXT_TIMEOUT environment variable

The TEMPORAL_CONTEXT_TIMEOUT environment variable specifies a timeout for the context of an RPC call in seconds. The default value is 5.

tctl requires a running Temporal Server

To use tctl, you must have a Temporal Server running.

tctl namespace register command modifiers

The tctl namespace register command accepts the following modifiers: --active_cluster (name of active cluster), --clusters (list of cluster names separated by spaces, only for Global Namespaces), --description (namespace description), --global_namespace (boolean to specify if namespace is global), --history_archival_state (disabled or enabled), --history_uri (archival URI), --namespace_data (key-value pairs like k1:v1,k2:v2), --owner_email (owner email), --retention (retention period in days), --visibility_archival_state (disabled or enabled), --visibility_uri (visibility archival URI).

tctl namespace register sets global namespace as read-only

When registering a Namespace, the --global_namespace modifier and --clusters list are read-only settings that cannot be changed after registration.

tctl namespace register archival URI cannot be changed

When registering a Namespace, the --history_uri and --visibility_uri cannot be changed after Archival is first enabled.

tctl namespace update command modifiers

The tctl namespace update command accepts the following modifiers: --active_cluster (name of active cluster), --add_bad_binary (binary checksum to prevent command dispatch), --clusters (list of cluster names for failover), --description (namespace description), --history_archival_state (disabled or enabled), --history_uri (archival URI), --namespace_data (key-value pairs like k1:v1,k2:v2), --owner_email (owner email), --reason (reason for update), --remove_bad_binary (binary checksum to remove), --retention (retention days), --visibility_archival_state (disabled or enabled), --visibility_uri (visibility archival URI).

tctl namespace update add_bad_binary prevents dispatch

The --add_bad_binary modifier adds a binary checksum to use when resetting a Workflow Execution. Temporal will not dispatch any Commands to the given binary.

tctl namespace update clusters only valid for global namespaces

The --clusters modifier when updating a Namespace is only valid when the --global_namespace modifier is set to true.

tctl namespace register retention period applies to closed workflows

The --retention modifier sets the Retention Period for a Namespace, which applies to Closed Workflow Executions.

tctl namespace short command examples

Short aliases can be used with tctl namespace commands: tctl --ns your-namespace n re registers a namespace (n is short for namespace, re is short for register).

tctl namespace commands overview

The tctl namespace commands enable Namespace operations. The alias for namespace is 'n'. Available commands are: describe, list, register, and update.

tctl namespace describe command

The tctl namespace describe command describes a Namespace. The --namespace_id modifier is required unless the global --namespace modifier is specified. Example: tctl namespace describe --namespace_id <id> or tctl --namespace <name> describe.

tctl namespace list command

The tctl namespace list command lists all Namespaces. The command has no modifiers.

tctl taskqueue describe command

The tctl taskqueue describe command describes the poller information of a Task Queue. The syntax is: tctl taskqueue describe <modifiers> <value>. The required --taskqueue (alias: --t) modifier specifies which Task Queue to describe. The optional --taskqueuetype modifier specifies the type of Task Queue, which can be 'workflow' or 'activity', with 'workflow' as the default.

tctl taskqueue list-partition command

The tctl taskqueue list-partition command lists the partitions of a Task Queue and the hostname for each partition. The syntax is: tctl taskqueue list-partition --taskqueue <value>. The required --taskqueue (alias: --t) modifier specifies which Task Queue to query.

Schedule update with tctl command syntax

To update a Schedule using tctl: tctl schedule update takes the same options as tctl schedule create and replaces the entire configuration of the Schedule with what is provided. If you want to change only one value, you must provide all other configuration values again.

Schedule backfill with tctl command syntax

To backfill a Schedule using tctl, run: tctl schedule backfill --sid 'your-schedule-id' --overlap-policy 'BufferAll' --start-time '2022-05-01T00:00:00Z' --end-time '2022-05-31T23:59:59Z'. Backfilling means having a Schedule do now what it would have done over a specified time range, typically used to fill in runs from a time period when the Schedule was paused or before it was created.

Schedule backfill overlap policy recommendations

When backfilling a Schedule, you should override the Overlap Policy. Specifying AllowAll runs all backfilled Workflows at once; BufferAll runs them sequentially. The other policies do not make much sense in the backfill context.

Schedule create with tctl command syntax

To create a Schedule using tctl, run: tctl config set version next, then tctl schedule create --schedule-id 'your-schedule-id' --interval '5h/15m' --calendar '{"dayOfWeek":"Fri","hour":"11","minute":"3"}' --overlap-policy 'BufferAll' --workflow-id 'your-workflow-id' --task-queue 'your-task-queue' --workflow-type 'YourWorkflowType'. This creates a Schedule that triggers every 5 hours at 15 minutes past the hour and also at 11:03 on Fridays, starting the specified Workflow on the Task Queue with a generated Workflow Id.

Schedule create with cron syntax using tctl

To create a Schedule using cron syntax with tctl: tctl schedule create --schedule-id 'your-schedule-id' --cron '3 11 * * Fri' --workflow-id 'your-workflow-id' --task-queue 'your-task-queue' --workflow-type 'YourWorkflowType'. Temporal Workflow Schedule Cron strings support traditional cron format, including shorthands like @weekly, @every, and CRON_TZ.

Schedule create with multiple time specifications

Any combination of --calendar, --interval, and --cron is supported when creating a Schedule, and Actions will happen at any of the specified times. If using both --time-zone and CRON_TZ, they must agree.

Schedule delete with tctl command syntax

To delete a Schedule using tctl: tctl schedule delete --schedule-id 'your-schedule-id'.

Deleting a Schedule does not affect existing Workflow Executions

Deleting a Schedule does not affect any Workflows started by the Schedule. Workflow Executions started by Schedules can be cancelled or terminated using the same methods as any other Workflow. Workflow Executions started by a Schedule can be identified by Search Attributes added to them and can be targeted by a batch command for termination.

Schedule describe with tctl command syntax

To display the current Schedule configuration along with information about past, current, and future Runs using tctl: tctl schedule describe --schedule-id 'your-schedule-id'. The Schedule Spec is converted to canonical representations, so the output might not be in the same form as it was input.

Schedule list with tctl command syntax

To list all Schedules using tctl: tctl schedule list. The output converts the Schedule Spec to canonical representations, so the output might not be in the same form as it was input.

Schedule toggle pause with tctl command syntax

To pause a Schedule using tctl: tctl schedule toggle --schedule-id 'your-schedule-id' --pause --reason "paused because the database is down". To unpause: tctl schedule toggle --schedule-id 'your-schedule-id' --unpause --reason "the database is back up".

Schedule trigger with tctl command syntax

To start a Workflow Run immediately with a Schedule regardless of its configured Spec using tctl: tctl schedule trigger --schedule-id 'your-schedule-id'. The triggered Action is subject to the Overlap Policy of the Schedule by default. To override and force immediate execution: tctl schedule trigger --schedule-id 'your-schedule-id' --overlap-policy 'AllowAll'.

Schedule trigger respects Overlap Policy by default

When triggering a Schedule action with tctl, the action is subject to the Schedule's Overlap Policy by default. If the overlap policy is Skip and a Workflow is already running, the triggered Action is skipped. If the overlap policy is BufferAll, the triggered run is buffered behind existing runs. To override this behavior, use --overlap-policy 'AllowAll'.

Check Frontend Service connectivity with temporal CLI

OSS users can verify that the Frontend Service is connected and running using the Temporal CLI command: temporal operator cluster health --address 127.0.0.1:7233

tctl workflow terminate records WorkflowExecutionTerminated event

The tctl workflow terminate command terminates a Workflow Execution, recording a WorkflowExecutionTerminated event as the closing event in the History. No more Workflow Tasks will be scheduled after termination.

tctl workflow cancel vs terminate

tctl workflow cancel records a WorkflowExecutionCancelRequested event and schedules a new Workflow Task for cleanup, while tctl workflow terminate records a WorkflowExecutionTerminated event and schedules no further Workflow Tasks.

tctl workflow count requires Elasticsearch

The tctl workflow count command counts Workflow Executions but requires Elasticsearch to be enabled.

tctl workflow describe shows latest Workflow Execution by default

The tctl workflow describe command shows information about a Workflow Execution. If a Run Id is not provided, the command shows the latest Workflow Execution of that Workflow Id.

tctl is deprecated in favor of Temporal CLI

The tctl command line utility has been deprecated and is no longer actively supported. Users are recommended to transition to Temporal CLI for continued use and access to new features.

tctl workflow cancel records WorkflowExecutionCancelRequested event

Canceling a running Workflow Execution using tctl workflow cancel records a WorkflowExecutionCancelRequested event in the History. A new Workflow Task will be scheduled, allowing the Workflow Execution to perform cleanup work after cancellation.

tctl workflow list defaults to listing closed Workflow Executions

The tctl workflow list command lists a maximum of 10 closed Workflow Executions by default. Use the --open option to list open Workflow Executions, --pagesize to set page size, and --more to list multiple pages.

tctl workflow list --query requires Advanced Visibility

The --query flag for tctl workflow list is supported only when Advanced Visibility is configured with the Cluster. Using the --query option causes tctl to ignore all other filter options, including open, earliest_time, latest_time, workflow_id, and workflow_type.

tctl workflow list earliest_time and latest_time format options

The --earliest_time and --latest_time modifiers for tctl workflow list support three format types: ISO 8601 format (year-month-dayThour:minute:second±offsethours:offsetminutes), raw Unix Epoch time in milliseconds since January 1, 1970 UTC, or relative duration format (<n><duration> where duration is one of: second/s, minute/m, hour/h, day/d, week/w, month/M, year/y).

tctl workflow list --status supported values

The --status modifier for tctl workflow list supports these values: completed, failed, canceled, terminated, continuedasnew, timedout.

tctl workflow listall lists all Workflow Executions

The tctl workflow listall command lists all open or closed Workflow Executions. By default, it lists all closed Workflow Executions. Use the --open option to list open Workflow Executions.

tctl workflow listarchived defaults to 100 Workflow Executions per page

The tctl workflow listarchived command lists archived Workflow Executions with a default page size of 100. Use --pagesize to set a custom page size and --all to list all pages.

tctl workflow observe shows Workflow Execution Event History progress

The tctl workflow observe command shows the progress of the Event History of a Workflow Execution. Use --show_detail to show event details and --max_field_length to specify the maximum length for each attribute field.

tctl workflow query can retrieve Workflow state

The tctl workflow query command sends a Query to a Workflow Execution to retrieve all or part of the Workflow state with given parameters. Queries can be used on both running and completed Workflows.

tctl workflow start generates UUID if Workflow Id not provided

If a Workflow is started without providing a Workflow Id, the Client generates one in the form of a UUID. Temporal recommends using a business id rather than the client-generated UUID.

Multiple Workflows with same Id cannot run simultaneously

Multiple Workflows with the same Id cannot be run at the same time.

tctl workflow terminate default run_id behavior

If run_id is not specified in tctl workflow terminate, tctl terminates the last Workflow Execution for the specified workflow_id.

tctl workflow query --query_reject_condition values

The --query_reject_condition modifier for tctl workflow query supports these values: not_open and not_completed_cleanly.

tctl workflow reset resets Workflow Execution from a point

The tctl workflow reset command resets a Workflow Execution by either eventId or resetType. Resetting allows the process to be resumed from a certain point without losing parameters or Event History.

tctl workflow reset --reset_type values

The --reset_type modifier for tctl workflow reset supports these values: FirstWorkflowTask (reset to beginning of Event History), LastWorkflowTask (reset to end of Event History), LastContinuedAsNew (reset to end of Event History for previous Run), BadBinary (reset to point where bad binary was used).

Give your agent this brain