This message was deleted.

You are correct: Flyte already exposes comprehensive workflow and task execution status via its control plane APIs and database, which serve as the source of truth for execution metadata. The control plane database holds execution records, including run and action (task) status, timing, error messages, and parent/child relationships; the Flyte UI and REST/gRPC APIs surface this information directly, making it unnecessary to duplicate status tracking in an external (DTP) database for execution status purposes. The DTP database is not required for retrieving workflow or task status, as Flyte's APIs provide this data natively and efficiently, avoiding redundant and potentially expensive I/O operations involved in update_status calls to DTP for information already present in Flyte's own database. However, if DTP has other use cases (e.g., custom business logic, audit trails, or integration with non-Flyte systems), it may still be needed for those scenarios. For execution status, Flyte's APIs and database are sufficient and recommended as the authoritative source. Would you like a detailed breakdown of how Flyte stores and exposes execution metadata, or examples of querying this information via API? Sources: - What goes in the database - Building a Gateway to Flyte - Runs and actions 👍 0 button 👎 0 button 💡 Hint: Mention @herald in the thread for followups.

yes, and also if I am running mutliple like 100's of workflows will flyte db works like external db? @ancient-wolf-19325

Yes, Flyte's control plane database is designed to handle metadata for hundreds or thousands of concurrent workflows and tasks, storing execution records, status, and lineage efficiently. However, it is not intended to serve as a general-purpose external database for arbitrary user data; it is optimized for Flyte's internal metadata (registrations, executions, schedules, pointers to data in object storage) and not for storing large or custom datasets unrelated to workflow orchestration. For large-scale workflow execution, Flyte's database scales well for metadata, but bulk data (inputs/outputs, files, DataFrames) is stored in object storage (e.g., S3, GCS), not in the database itself. If you need a database for application data outside of Flyte's orchestration metadata, you should use a dedicated external database. Would you like more detail on Flyte's data storage architecture or scaling characteristics? Sources: - What goes in the database 👍 0 button 👎 0 button 💡 Hint: Mention @herald in the thread for followups.

how to get the flyte db task status?

You can get task status directly from Flyte using its APIs, not by querying the underlying database. Use the Flyte CLI (

flyte get run <run-id>

) or the Python SDK (

run.status

), or access the REST/gRPC APIs that the Flyte UI uses to retrieve task and workflow status. The database itself is not meant for direct user queries; all status information is exposed via these APIs. Would you like more detail or code examples for using the CLI, Python SDK, or REST API? Sources: - Flyte CLI and Python SDK for status - What goes in the database 👍 0 button 👎 0 button 💡 Hint: Mention @herald in the thread for followups.

i already submitted a V1 workflow through pyflyte command, how to get the details of job status which command to use? @ancient-wolf-19325

Use the command

flytectl get execution --project <project> --domain <domain> <execution_name>

to get the status and details of a V1 workflow submitted via

pyflyte

. This will show the current phase, inputs, outputs, and logs for the execution. Would you like more detail or examples for interpreting the output? Sources: - Running workflows and inspecting status with pyflyte and FlyteConsole 👍 0 button 👎 0 button 💡 Hint: Mention @herald in the thread for followups.

curl -sL ctl.flyte.org/install | sudo bash -s -- -b /usr/local/bin flyteorg/flyte info checking GitHub for latest tag flyteorg/flyte crit unable to find '' - use 'latest' or see github.com/flyteorg/flyte/releases for details @ancient-wolf-19325

It seems likely that this error occurs because the install script cannot find the latest release tag for Flytectl. This can happen if the GitHub API is unreachable or if the script is not parsing the release tags correctly. The script expects to find a valid release, or you can specify

latest

explicitly. Try running:

curl -sL https://ctl.flyte.org/install | sudo bash -s -- -b /usr/local/bin -v latest

Or manually download the binary from the Flytectl releases page. Would you like more troubleshooting steps or details about the install process? Sources: - Flytectl install instructions 👍 0 button 👎 0 button 💡 Hint: Mention @herald in the thread for followups.

this command is giving overal workflow status how to get each task status? flytectl --config /opt/flyte/flyteconfig.yaml get execution -p playground -d prod asn66fgh8kzgv8jfsfvx @ancient-wolf-19325

To get each task's status within a workflow execution, use the

--details

flag with your command. This will show node and task execution details, including their statuses. Example:

flytectl --config /opt/flyte/flyteconfig.yaml get execution -p playground -d prod asn66fgh8kzgv8jfsfvx --details

Would you like more detail on interpreting the output or extracting specific task statuses? Sources: - Inspecting executions with --details 👍 0 button 👎 0 button 💡 Hint: Mention @herald in the thread for followups.

just provide a simple workflow that run two tasks which run one after other and also i want to see the job status in the same workflow the job status is pass or fail seperately can you please provide the code @ancient-wolf-19325

It seems likely that you can define a simple Flyte workflow with two tasks running sequentially, and a third task to check and report the status (pass/fail) of the previous tasks. In Flyte V1, you can use try/except logic inside a task to capture status, but Flyte workflows themselves do not natively expose task status as a variable—status is tracked by the platform and visible via the UI or API. However, you can simulate status reporting by catching exceptions and returning a status string. Here’s a minimal Flyte V1 example:

from flytekit import task, workflow

@task
def task1(x: int) -> int:
    return x + 1

@task
def task2(y: int) -> int:
    return y * 2

@task
def status_task(success: bool) -> str:
    return "pass" if success else "fail"

@workflow
def simple_wf(x: int) -> (int, int, str):
    try:
        a = task1(x=x)
        b = task2(y=a)
        status = status_task(success=True)
    except Exception:
        a = b = None
        status = status_task(success=False)
    return a, b, status

This workflow runs

task1

, then

task2

, and finally reports "pass" if both succeed, "fail" otherwise. Would you like a Flyte 2 (new API) version or more detail? Sources: - Flyte V1 workflow basics - Error handling in workflows 👍 0 button 👎 0 button 💡 Hint: Mention @herald in the thread for followups.