Activate, pause, inspect, and delete triggers

Initialize the remote client and identify the trigger

Before activating, inspecting, or deleting a deployed trigger, initialize Flyte with the project and domain that contain it. Remote trigger methods call ensure_client() and build trigger identifiers from the initialized organization, project, and domain. A trigger is identified by both its trigger name and its associated task name.

The CLI initializes that context before calling the remote façade:

from flyte.remote import Trigger

cfg.init(project=project, domain=domain)

if name:
    console.print(pretty_repr(Trigger.get(name=name, task_name=task_name)))
else:
    console.print(common.format("Triggers", Trigger.listall(task_name=task_name, limit=limit), cfg.output_format))

The corresponding CLI validation rejects a trigger name without a task name:

if name and not task_name:
    raise click.BadParameter("If you provide a trigger name, you must also provide the task name.")

The same composite identity is required by Trigger.get, TriggerDetails.get, Trigger.update, and Trigger.delete.

Deploy a trigger for a task

Construct a user-facing flyte.Trigger and pass it to flyte.remote.Trigger.create. The CLI's deployment path uses a cron schedule and optionally maps the trigger time into a task input:

from flyte.remote import Trigger

cfg.init(project, domain)
console = common.get_console()

trigger = flyte.Trigger(
    name=name,
    automation=flyte.Cron(schedule),
    description=description,
    auto_activate=auto_activate,
    inputs={trigger_time_var: flyte.TriggerTime},  # Use the trigger time variable in inputs
    env_vars=None,
    interruptible=None,
)
with console.status("Creating trigger..."):
    v = Trigger.create(trigger, task_name=task_name)
console.print(f"[bold green]Trigger {v.name} created successfully![/bold green]")

Trigger.create(trigger, task_name, task_version=None) is a synchronous wrapper around an asynchronous classmethod. Internally it obtains a remote task through Task.get(...).fetch.aio(). With an explicit task_version, it fetches that version; without one, it creates a lazy task handle with auto_version="latest" and fetches the latest version at creation time. It then passes the fetched task's interface inputs and default inputs to trigger_serde.to_task_trigger before calling the trigger deployment RPC. The deployed trigger's task_version is the resolved task version; latest is not stored as a moving alias.

A task handle itself is lazy:

lazy_task = Task.get(task_name, project=project, domain=domain, auto_version="latest")
task_details = await lazy_task.fetch.aio()

Creating lazy_task does not make the remote request. Fetching it does. Trigger creation performs that fetch as part of deployment. If the task lookup returns a ConnectRPC NOT_FOUND, Trigger.create raises ValueError with the form Task {task_name}:{version or latest} not found; other ConnectRPC errors are re-raised.

Inspect and list deployed triggers

Retrieve one trigger

Use Trigger.get when you have both the trigger and task names:

console.print(pretty_repr(Trigger.get(name=name, task_name=task_name)))

Trigger.get delegates to TriggerDetails.get, which calls trigger_service.get_trigger_details with a configured organization, project, domain, trigger name, and task name. The returned TriggerDetails exposes:

name, id, and task_name
automation_spec
metadata
status
is_active

You can also call the detail façade directly when you need to make the composite identity explicit:

from flyte.remote._trigger import TriggerDetails

details = TriggerDetails.get(name=trigger_name, task_name=task_name)
print(details.name, details.task_name, details.is_active)
print(details.status)
print(details.metadata)

The TriggerDetails.trigger property is a cached protobuf reconstructed from the detail response. It combines the detail response's identifier, automation specification, metadata, status, and active flag; accessing it does not perform another server fetch.

A Trigger returned by Trigger.create or Trigger.listall exposes the lighter-weight view:

print(trigger.name)
print(trigger.task_name)
print(trigger.is_active)
print(trigger.automation_spec)
print(trigger.url)

List triggers by scope

Trigger.listall(task_name=None, task_version=None, limit=100) is a paginated async generator. It has three request scopes:

task_name and task_version: an exact task identifier.
task_name only: all trigger resources associated with that task name across versions.
No task_name: all triggers in the initialized project and domain.

The CLI uses the latter two forms:

if name:
    console.print(pretty_repr(Trigger.get(name=name, task_name=task_name)))
else:
    console.print(common.format("Triggers", Trigger.listall(task_name=task_name, limit=limit), cfg.output_format))

The implementation forwards limit to each ListTriggersRequest, follows the response continuation token, and stops when the server returns no token. Treat limit as the server page size rather than a guaranteed client-side total-result cap.

Activate or pause a schedule

Use Trigger.update as a state setter. Pass active=True to activate a trigger and active=False to deactivate it. Although the method's docstring says “Pause a trigger,” its active argument supports both states. The CLI calls the method directly for either operation:

def trigger(cfg: common.CLIConfig, name: str, task_name: str, activate: bool, project: str | None, domain: str | None):
    cfg.init(project, domain)
    console = common.get_console()
    to_state = "active" if activate else "deactivate"
    with console.status(f"Updating trigger {name} for task {task_name} to {to_state}..."):
        remote.Trigger.update(name, task_name, activate)
    console.print(f"Trigger updated and is set to [fuchsia]{to_state}[/fuchsia]")

For asynchronous integrations, use the .aio variant exposed by the syncify wrapper. The webhook application checks its trigger allowlist before making the update and uses both activation states:

await remote.Trigger.update.aio(name=trigger_name, task_name=task_name, active=True)

await remote.Trigger.update.aio(name=trigger_name, task_name=task_name, active=False)

Trigger.update sends an UpdateTriggersRequest containing the composite trigger name and the requested active value. It does not return an updated Trigger object, so retrieve the trigger again with Trigger.get if you need to inspect the resulting server state.

Delete a trigger

Delete by supplying both names. Optional project and domain arguments allow deletion in a context other than the currently initialized project and domain:

from flyte.remote import Trigger

Trigger.delete(
    name=trigger_name,
    task_name=task_name,
    project=project,
    domain=domain,
)

When project or domain is omitted, Trigger.delete uses the initialized values. The method sends a DeleteTriggersRequest and returns no remote entity. Unlike get, update, and listall, deletion explicitly supports project and domain overrides; use those arguments when the target is outside the current context.

Locate a trigger in the Flyte console

A remote Trigger's url property delegates to the configured Console:

url = trigger.url

Console.trigger_url builds the path by placing the task name and trigger name under the trigger resource:

url = console.trigger_url(
    project="myproject", domain="development", task_name="mytask", trigger_name="mytrigger"
)

For the tested HTTPS configuration, the result is:

https://example.com/v2/domain/development/project/myproject/triggers/mytask/mytrigger

The URL construction rules are:

Configuration	Resulting console base
`Console("https://example.com", insecure=False)`	`https://example.com`
`Console("dns:///example.com", insecure=False)`	`https://example.com`
`Console("dns:///localhost:8090", insecure=True)`	`http://localhost:8080`
`Console("dns:///localhost:8090", insecure=False)`	`https://localhost:8080`

insecure=True selects plain HTTP for console links. The localhost:8090 to localhost:8080 mapping is a built-in local-development special case. Console constructs URLs as strings and does not URL-escape project, domain, task, or trigger names, so names containing URL-special characters can produce malformed links.

Troubleshoot lifecycle operations

Client initialization errors: Trigger and task operations call ensure_client() and read the initialized organization, project, and domain. Initialize Flyte first, for example through the project's flyte.init_from_config(), flyte.init_from_api_key(), or flyte.init(...) paths.
Missing task name: A trigger name alone is insufficient. Supply task_name to get, update, and delete; use the CLI validation pattern shown above.
Unexpected task version at creation: Without task_version, Trigger.create resolves auto_version="latest" during creation and binds the deployment to the version selected then. It will not follow later task deployments.
Lazy task lookup: Task.get only creates a lazy handle. Call .fetch() or .fetch.aio() to contact the API and validate the task. Automatic versions are limited to `

Initialize the remote client and identify the trigger​

Deploy a trigger for a task​

Inspect and list deployed triggers​

Retrieve one trigger​

List triggers by scope​

Activate or pause a schedule​

Delete a trigger​

Locate a trigger in the Flyte console​

Troubleshoot lifecycle operations​