WORKFLOW · PARENT OUTPUT
Griptape-style workflow: honor a parent-output dependency
Two child tasks need a parent task’s summary and risk flags. Launch them on a dependency edge, all at once, or by polling, and see what they read.
Your experiment
Parent task P summarises a supplier contract and writes {summary, risk_flags}. C1 drafts an email from the summary and C2 reviews the risk flags. The store still holds run 41’s result. Start with children launched alongside the parent, then add an edge, polling, run scoping and atomic writes.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, Speed changes the pace and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Teaching model of a task workflow in the style of Griptape’s parent and child tasks; it is not the Griptape API. Streaming writes the summary at half the parent’s duration and the risk flags at the end; polling checks once per second. No model or workflow engine runs.
Children that start too early
Parent task P summarises a supplier contract in 6 seconds and writes a summary and two risk flags. Child C1 drafts an email from the summary and C2 reviews the risk flags. In the opening run both children are launched with the parent at 0 seconds, and the output store still holds run 41’s result for the same task name, so both read the previous contract: WRONG PARENT OUTPUT, 0 of 2 children correct. Nothing in the run status shows it.
A dependency edge
Set How child tasks start to Dependency edge: after the parent completes. Both children start at 6 seconds with run 42’s complete output: DEPENDENCY HONORED. This is what a parent-child edge in a workflow means; the scheduler, not the child, decides when the input is ready. Shorten Parent task duration to 2 seconds and the children start at 2 seconds; lengthen it to 10 seconds and they start at 10.
Polling for a value is not a dependency
Choose Poll the output store until it is non-empty. Without run scoping the stale run 41 value is non-empty at 0 seconds, so both children read it immediately. Check Output store is keyed by run id: C1 now waits until the first streamed chunk at 3 seconds and gets a complete summary, but C2 reads before the risk flags exist and reports no risks: 1 of 2 correct.
Atomic writes and run scoping
How the parent writes its output matters when children poll a run-scoped store. Written once at the end makes the first non-empty value the complete one, so polling happens to work: 2 of 2 at 6 seconds. Launched with the parent and a run-scoped store gives empty inputs instead of stale ones: still 0 of 2, but at least the failure is visible. Scope outputs to the run and start children on completion.
Reading the run and its limits
Play, Next event, Restart, Speed and Inspection time step through the start, the parent’s writes, each child’s read and the result across sixty seconds; the table records when each child started and what it saw. This model is in the style of Griptape parent and child tasks but is not its API; streaming timing and polling interval are fixed fixture values.