Summary

When a flow run transitions to CRASHED state (e.g., OOM killed in Kubernetes), automatically transition all non-terminal child task runs to CRASHED as well.

• AddsCrashChildTaskRuns transform toGlobalFlowPolicy
• Follows the same pattern asUpdateSubflowParentTask
• Ensures task runs don't remain stuck in RUNNING state when their parent flow crashes

Scope and behavior

What this handles

Nested tasks (tasks calling tasks): All tasks within a flow share the sameflow_run_id regardless of nesting depth. Whentask_a callstask_b callstask_c, they all have the sameflow_run_id. The fix correctly crashes all of them when the parent flow crashes.

All non-terminal task states: PENDING, RUNNING, SCHEDULED, PAUSED - any task that hasn't reached a terminal state will be transitioned to CRASHED.

Terminal tasks preserved: Tasks that have already COMPLETED, FAILED, CANCELLED, or CRASHED are not modified.

What this does NOT handle (separate concern)

Subflows: When a flow calls another flow as a subflow, that subflow is a separate flow run with its ownflow_run_id. The subflow's "parent task run" (in the parent flow) WILL be crashed by this fix, but the subflow itself won't be automatically cascaded to CRASHED. This is arguably a separate feature request, as subflows are architecturally independent flow runs that can be retried independently.

Test plan

• Unit tests intests/server/orchestration/test_global_policy.py:
  • test_crash_child_task_runs_when_flow_crashes
  • test_does_not_crash_already_terminal_task_runs
  • test_does_not_crash_tasks_for_non_crashed_transitions
• Integration tests inintegration-tests/test_crash_child_task_runs.py:
  • test_child_task_runs_crash_when_flow_crashes
  • test_does_not_crash_already_completed_tasks
  • test_crash_propagates_to_pending_tasks
• Manual testing with Kubernetes work pool to verify OOM crash scenario

Fixes#19594

🤖 Generated withClaude Code