Documentation Index
Fetch the complete documentation index at: https://launchpad.datalumina.com/llms.txt
Use this file to discover all available pages before exploring further.
The task context is a stateful Pydantic model used throughout the workflow. It provides a single reference point accessible from any node, so relevant data can be stored and retrieved as needed.
TaskContext Class
TheTaskContext class serves as the central data container for workflow execution:
event— the original triggering event, parsed against the workflow’sevent_schema.nodes— results from each node’s execution, keyed by class name.metadata— workflow-level metadata (the workflow orchestrator stores the node registry here undermetadata["nodes"]).should_stop— set toTrueviastop_workflow()to halt execution cleanly after the current node finishes.trace_id— Langfuse trace ID captured on entry whenenable_tracing=True; useful when you want to log or surface the trace URL back to the caller.
The Event Attribute
Theevent attribute in TaskContext serves as the main entry point for workflow input data. When a workflow is initialized, the provided event is parsed according to the event_schema specified within the WorkflowSchema.
This mechanism supports many event formats because each workflow defines its own event schema. You can run multiple workflows for different inputs without changing the shared workflow infrastructure.
Example WorkflowSchema:
Type Hinting
By default, theevent attribute of TaskContext has the type Any, which means you won’t get autocomplete or type checking when accessing its fields or methods.
However, since each workflow defines its own event_schema, you already know the expected structure of event within that workflow.
To benefit from IDE features like autocomplete and static type checking, explicitly type the event attribute when retrieving it from the TaskContext. This makes your code more readable and helps catch errors earlier.
Example:
- Define Event Schema - Create a Pydantic model for your event structure
- Configure Workflow - Set the event_schema in your WorkflowSchema
- Type the Event - Cast the event to your schema type in node processing
- Enjoy Type Safety - Get full IDE support and compile-time error checking
Stopping a workflow mid-flight
Any node can halt the run after it returns by callingtask_context.stop_workflow(). The orchestrator checks should_stop between nodes and exits the loop cleanly, preserving everything saved so far. Typical uses: a guardrail node detects a prompt injection, or a router decides there is nothing left to do.
Best practices
- Event schema design: Use specific, well-described field names
- Node result storage: Store results under the node class name for consistency
- Metadata usage: Keep workflow-level configuration in metadata
- Type safety: Cast the event to your schema type in node processing