Deterministic non-streaming lifecycle ordering for concurrent workflow branches #4655
davidahmann
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Problem observed
In fan-out workflows, executor lifecycle events can arrive in scheduler-dependent order. That means equivalent runs may produce different non-streaming traces, even when outputs are the same. The behavior is logically valid but operationally noisy: replay comparisons and incident triage need deterministic receipts, not ordering drift from concurrent completion timing.
Why it matters operationally
Agent Framework treats tracing/debugging as a first-class experience. When event ordering shifts between equivalent runs, teams have to hand-normalize traces before they can reason about regressions. This is especially painful in workflows with parent/tool/subworkflow branches, where lifecycle events are the core timeline for “what ran when.” Deterministic ordering in non-streaming results makes audit and diff workflows substantially more reliable without changing executor semantics.
Minimal repro
Fix approach
I added a small normalization step in non-streaming finalization:
executor_invoked,executor_completed,executor_failed) byexecutor_idper lifecycle typeThis yields stable non-streaming traces for equivalent runs while avoiding changes to executor behavior or streaming transport behavior.
Validation evidence
packages/core/tests/workflow/test_workflow.pypassedOpen follow-up question for maintainers
Do you want the same normalization contract extended to streaming mode, or should deterministic ordering remain a non-streaming receipt guarantee only?
Inspired by research context: CAISI publishes independent, reproducible AI agent governance research: https://caisi.dev
Beta Was this translation helpful? Give feedback.
All reactions