mirror of
https://github.com/hatchet-dev/hatchet.git
synced 2026-04-22 10:10:07 -05:00
fix: rm workflows page for now
This commit is contained in:
mrkaye97
@@ -14,10 +14,6 @@ export default {
|
||||
workers: "Workers",
|
||||
"running-your-task": "Running Tasks",
|
||||
"durable-execution": "Durable Execution",
|
||||
workflows: {
|
||||
title: "Workflows",
|
||||
display: "hidden",
|
||||
},
|
||||
"--triggers": {
|
||||
title: "Triggers",
|
||||
type: "separator",
|
||||
|
||||
@@ -1,198 +0,0 @@
|
||||
import { Callout, Cards, Steps, Tabs } from "nextra/components";
|
||||
import UniversalTabs from "@/components/UniversalTabs";
|
||||
import { Snippet } from "@/components/code";
|
||||
import { snippets } from "@/lib/generated/snippets";
|
||||
import DurableWorkflowComparisonDiagram from "@/components/DurableWorkflowComparisonDiagram";
|
||||
import WorkflowDiagram from "@/components/WorkflowDiagram";
|
||||
import PipelineDiagram from "@/components/PipelineDiagram";
|
||||
import CycleDiagram from "@/components/CycleDiagramWrapper";
|
||||
import BatchProcessingDiagram from "@/components/BatchProcessingDiagramWrapper";
|
||||
import Keywords from "@/components/Keywords";
|
||||
|
||||
# Workflows
|
||||
|
||||
In Hatchet, you can compose [tasks](/v1/tasks) into **workflows** in two ways: [declaratively as a DAG](#directed-acyclic-graphs-dags) (or as a non-DAG workflow) by registering tasks with explicit dependencies, or dynamically at runtime via [child spawning](#child-spawning). These options can be combined to build complicated workflows that fit the application's needs.
|
||||
|
||||
<Callout type="info">
|
||||
All workflows in Hatchet, whether or not they're comprised of durable tasks, are **durable** — the workflow itself persists state between tasks and can be rerun from specific checkpoints, even if a worker crashes.
|
||||
|
||||
{/* TODO-DOCS: Link to durable execution docs here */}
|
||||
|
||||
</Callout>
|
||||
|
||||
It's sometimes helpful to think of a workflow as an abstraction on top of DAGs and individual tasks. In broad strokes, a workflow is the abstraction that can represent any composition of tasks, whether into a DAG or otherwise. A workflow can have a single task (a "standalone" task), or it can be a complicated DAG. It can model a fanout pattern, an agent loop, or any other shape or feature that the application needs.
|
||||
|
||||
## Directed Acyclic Graphs (DAGs)
|
||||
|
||||
Hatchet lets you represent DAGs by specifying parents on any given task in a workflow.
|
||||
|
||||
<Callout type="info">
|
||||
If you're not familiar, a [directed acyclic
|
||||
graph](https://en.wikipedia.org/wiki/Directed_acyclic_graph), or DAG, is a way
|
||||
of organizing tasks such that they are run in a specific order, with provided
|
||||
dependencies.
|
||||
</Callout>
|
||||
|
||||
You define DAGs in Hatchet _declaratively_, meaning a workflow registered on a worker has a pre-defined shape. This lets you split up the work into smaller chunks that can run concurrently and have specific dependencies between them:
|
||||
|
||||
<WorkflowDiagram />
|
||||
|
||||
### Defining a DAG
|
||||
|
||||
Start by declaring a workflow with a name. The workflow object can declare additional workflow-level configuration options. The returned object is the primary interface for running the workflow.
|
||||
|
||||
<UniversalTabs items={["Python", "Typescript", "Go", "Ruby"]}>
|
||||
<Tabs.Tab title="Python">
|
||||
|
||||
<Snippet src={snippets.python.dag.worker.define_a_dag} />
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab title="Typescript">
|
||||
|
||||
<Snippet src={snippets.typescript.dag.workflow.declaring_a_dag_workflow} />
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab title="Go">
|
||||
|
||||
<Snippet src={snippets.go.dag.main.declaring_a_workflow} />
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab title="Ruby">
|
||||
<Snippet src={snippets.ruby.dag.worker.define_a_dag} />
|
||||
</Tabs.Tab>
|
||||
</UniversalTabs>
|
||||
|
||||
<Callout variant="info">
|
||||
The workflow constructor accepts a number of configuration options, similarly
|
||||
to that of the [task](/v1/tasks). However, it only accepts the subset of
|
||||
options that apply at the workflow level.
|
||||
</Callout>
|
||||
|
||||
### Adding a task to a workflow
|
||||
|
||||
Add tasks to the workflow by calling the `task` method, which binds the task to the workflow. Tasks receive the workflow's input and return their own output. They also accept configuration options for retries, timeouts, and more.
|
||||
|
||||
<UniversalTabs items={["Python", "Typescript", "Go", "Ruby"]} variant="hidden">
|
||||
<Tabs.Tab title="Python">
|
||||
|
||||
In Python, `task` is a decorator:
|
||||
|
||||
<Snippet src={snippets.python.dag.worker.first_task} />
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab title="Typescript">
|
||||
|
||||
<Snippet src={snippets.typescript.dag.workflow.first_task} />
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab title="Go">
|
||||
|
||||
<Snippet src={snippets.go.dag.main.defining_a_task} />
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab title="Ruby">
|
||||
<Snippet src={snippets.ruby.dag.worker.first_task} />
|
||||
</Tabs.Tab>
|
||||
</UniversalTabs>
|
||||
|
||||
### Building a DAG with task dependencies
|
||||
|
||||
Tasks specify parent dependencies that must complete before they can start. This connects tasks into a graph structure.
|
||||
|
||||
<UniversalTabs items={["Python", "Typescript", "Go", "Ruby"]} variant="hidden">
|
||||
<Tabs.Tab title="Python">
|
||||
|
||||
<Snippet src={snippets.python.dag.worker.task_with_parents} />
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab title="Typescript">
|
||||
|
||||
<Snippet src={snippets.typescript.dag.workflow.second_task_with_parent} />
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab title="Go">
|
||||
|
||||
<Snippet src={snippets.go.dag.main.adding_a_task_with_a_parent} />
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab title="Ruby">
|
||||
<Snippet src={snippets.ruby.dag.worker.task_with_parents} />
|
||||
</Tabs.Tab>
|
||||
</UniversalTabs>
|
||||
|
||||
### Accessing parent task outputs
|
||||
|
||||
Downstream tasks in a DAG can access outputs from their parents via the context object:
|
||||
|
||||
<UniversalTabs items={["Python", "Typescript", "Go", "Ruby"]} variant="hidden">
|
||||
<Tabs.Tab title="Python">
|
||||
|
||||
<Snippet src={snippets.python.dag.worker.task_with_parents} />
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab title="Typescript">
|
||||
|
||||
<Snippet src={snippets.typescript.dag.workflow.accessing_parent_outputs} />
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab title="Go">
|
||||
|
||||
{/* TODO-DOCS: Snippet here */}
|
||||
|
||||
```go
|
||||
var parentOutput ParentOutputType
|
||||
err := ctx.ParentOutput(parentTask, &parentOutput)
|
||||
if err != nil {
|
||||
return nil, err
|
||||
}
|
||||
```
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab title="Ruby">
|
||||
<Snippet src={snippets.ruby.dag.worker.task_with_parents} />
|
||||
</Tabs.Tab>
|
||||
</UniversalTabs>
|
||||
|
||||
### Learn More
|
||||
|
||||
To learn more about building DAGs declaratively, check out the [DAG Documentation](/v1/patterns/directed-acyclic-graphs).
|
||||
|
||||
## Child Spawning
|
||||
|
||||
Workflows can also be constructed dynamically at runtime, via child spawning. Any task can spawn child tasks and workflows at runtime. Children run independently on any available worker, and the parent can optionally wait for their results.
|
||||
|
||||
<UniversalTabs items={["Python", "Typescript", "Go", "Ruby"]}>
|
||||
<Tabs.Tab title="Python">
|
||||
|
||||
Declare parent and child tasks:
|
||||
|
||||
<Snippet src={snippets.python.fanout.worker.fanout_parent} />
|
||||
|
||||
<Snippet src={snippets.python.fanout.worker.fanout_child} />
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab title="Typescript">
|
||||
|
||||
<Snippet
|
||||
src={snippets.typescript.simple.workflow_with_child.declaring_a_task}
|
||||
/>
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab title="Go">
|
||||
|
||||
<Snippet src={snippets.go.child_workflows.main.declaring_the_tasks} />
|
||||
|
||||
</Tabs.Tab>
|
||||
<Tabs.Tab title="Ruby">
|
||||
<Snippet src={snippets.ruby.fanout.worker.fanout_parent} />
|
||||
<Snippet src={snippets.ruby.fanout.worker.fanout_child} />
|
||||
</Tabs.Tab>
|
||||
</UniversalTabs>
|
||||
|
||||
Child spawning is especially useful if the shape of the workflow is unknown until runtime, such as in agentic applications.
|
||||
|
||||
### Learn More
|
||||
|
||||
For more details on child spawning, check out [the Child Spawning documentation](/v1/child-spawning).
|
||||
|
||||
<Keywords keywords="task, dag, workflow, child spawning" />
|
||||
Reference in New Issue
Block a user