Problem
When a parent recipe invokes sub-recipes via type: recipe steps, the parent-child relationship is not persisted to disk. The parent_session_id parameter flows through the executor call stack (in executor.py) but is only used for cancellation propagation — it never reaches create_session() in session.py and is never written to state.json.
This means:
- No way to correlate parent and child recipe sessions after execution — dashboards, audit tools, and monitoring cannot reconstruct the recipe hierarchy
- Parent recipes appear "stalled" — when a parent kicks off long-running sub-recipes, it stops updating its own
state.json. Time-based status detection (used by the recipe dashboard) marks the parent as stalled/idle even though its children are actively running
- No history of nested execution — for recipes that trigger multiple levels of sub-recipes (e.g., a discovery pipeline orchestrating code-tracer, behavior-observer, and synthesizer sub-recipes), there's no way to reconstruct what happened
Evidence
session.py:97-136 — create_session() writes 8 fields to state.json; no parent reference
executor.py:445 — parent_session_id parameter exists but is annotated "for cancellation checks"
executor.py:2484 — _execute_recipe_step() passes parent_session_id to recursive execute_recipe() but never persists it
- Verified across 399 real
state.json files on disk — zero contain parent_id or parent_session_id at the top level
Proposed Change (in amplifier-bundle-recipes)
session.py — Add parent_session_id: str | None = None parameter to create_session() and include "parent_session_id": parent_session_id in the state dict
executor.py — Pass parent_session_id through to create_session() at the call sites where sub-recipe sessions are created
- Backward compatible — existing
state.json files without the field continue to work; consumers treat missing/null parent_session_id as "no parent" (top-level recipe)
Downstream Impact
Once this field is persisted, downstream tools can:
- Build parent→child tree views of recipe execution
- Propagate status accurately (parent is "running" if any child is running)
- Show complete nested recipe hierarchies in dashboards
- Enable audit trails for complex multi-recipe workflows
Problem
When a parent recipe invokes sub-recipes via
type: recipesteps, the parent-child relationship is not persisted to disk. Theparent_session_idparameter flows through the executor call stack (inexecutor.py) but is only used for cancellation propagation — it never reachescreate_session()insession.pyand is never written tostate.json.This means:
state.json. Time-based status detection (used by the recipe dashboard) marks the parent as stalled/idle even though its children are actively runningEvidence
session.py:97-136—create_session()writes 8 fields tostate.json; no parent referenceexecutor.py:445—parent_session_idparameter exists but is annotated "for cancellation checks"executor.py:2484—_execute_recipe_step()passesparent_session_idto recursiveexecute_recipe()but never persists itstate.jsonfiles on disk — zero containparent_idorparent_session_idat the top levelProposed Change (in amplifier-bundle-recipes)
session.py— Addparent_session_id: str | None = Noneparameter tocreate_session()and include"parent_session_id": parent_session_idin the state dictexecutor.py— Passparent_session_idthrough tocreate_session()at the call sites where sub-recipe sessions are createdstate.jsonfiles without the field continue to work; consumers treat missing/nullparent_session_idas "no parent" (top-level recipe)Downstream Impact
Once this field is persisted, downstream tools can: