This exercise introduces the two fundamental building blocks of every Temporal application: workflows and activities. You will wrap the same National Weather Service API call from Exercise 1 inside a proper Temporal activity, orchestrate it from a workflow, and watch the full execution history appear in the Temporal UI atDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/temporalio/edu-ai-workshop-openai-agents-sdk/llms.txt
Use this file to discover all available pages before exploring further.
localhost:8233.
Timebox: 15 minutes — Work through
solutions/02_temporal_hello_world/solution.ipynb together during the workshop. Afterwards, practice in exercises/02_temporal_hello_world/exercise.ipynb.What You’ll Learn
Workflows & Activities
Understand the difference between a workflow (orchestration logic) and an activity (a unit of work with side effects).
Temporal UI
Navigate the workflow list, drill into execution history, and read event-level detail for each activity attempt.
Automatic Retries
See how Temporal re-attempts a failing activity according to its retry policy—no application code required.
Durable Execution
Kill the worker mid-execution, restart it, and observe the workflow resume from exactly where it stopped.
Goal
Build aHelloWorkflowTemporal that invokes get_weather_for_state("CA") as a Temporal activity and returns the result. Observe the end-to-end execution in the Temporal UI and confirm automatic retry behaviour.
Architecture
- Activities automatically retry on failure
- Workflow state persists across crashes
- Full execution history is recorded in Temporal UI
Solution Walkthrough
Install dependencies and import Temporal
UnsandboxedWorkflowRunner is required when running workflows inside a Jupyter notebook. Temporal’s default sandbox restricts certain Python operations that Jupyter relies on (like importing modules dynamically). In production Python scripts you omit this parameter and use the default sandboxed runner.Define the activity
Activities are decorated with
@activity.defn. They represent the actual work: I/O calls, database queries, anything with side effects. Temporal tracks each attempt individually and can retry on failure.Define the workflow
Workflows are decorated with
@workflow.defn. The @workflow.run method is the entry point. Workflows must not perform I/O directly—all side effects happen in activities scheduled via workflow.execute_activity().Start the worker
A worker polls a named task queue and executes any workflows or activities it is registered to handle.
Observing Execution in the Temporal UI
After running the starter cell, open the Temporal UI link printed to the console. You will see:Workflow Timeline
A visual timeline of every event: WorkflowExecutionStarted, ActivityTaskScheduled, ActivityTaskStarted, ActivityTaskCompleted, WorkflowExecutionCompleted.
Activity Detail
Click any ActivityTask event to inspect the input arguments, output payload, attempt number, and timing for that specific execution.
Execution History
The append-only event log that is the source of truth for Temporal’s durability guarantees. Every state transition is recorded here.
Worker Polling
In a separate tab you can watch the
hello-temporal-task-queue queue depth and see which workers are currently polling.Stretch Goal
Kill the worker mid-execution and restart it
Kill the worker mid-execution and restart it
- Start a new workflow execution (re-run the starter cell).
- Immediately cancel the
worker_taskbackground task in the notebook. - Watch the Temporal UI—the workflow enters a Running state waiting for a worker to pick up the pending activity.
- Restart the worker by re-running the worker cell.
- Observe the workflow resume and complete from the activity step, not from the beginning.