You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Per-step hook for trigger gates beyond run-start gating #160
The wayflowcore worker dispatches a flow via a single blocking client.sendTask call. Agent Spec already has a notion of trigger-gated runs (pending_trigger / armed lifecycle), but the gate is checked only at run-start — there's no per-step hook to inspect mid-flight node transitions and gate them on an external scheduler.
Use case
"Send the email when the trigger fires, not when the run dispatches."
With run-start gating only, the only way to express this is to split orchestration into multiple runs (lose the single-flow declarative narrative) or invent a custom node-type extension. Both approaches diverge across teams.
What would help (any of)
A documented per-step hook in the executor lifecycle that runtime adapters can wire to inspect / gate node transitions
A first-class executor for an external-wait node type that yields the conversation back to the caller pending an external resume signal
A spec-blessed pattern for resuming a paused conversation via a non-human-input event — companion to InputMessageNode for the scheduler case
Tactical workaround in use today
A custom node that yields with task_state="input-required" plus a vendor metadata.resumeSource="trigger-release" marker. The dispatcher detects the marker, persists the held a2aContextId, transitions the run to a custom waiting_* status, and exits cleanly. An external job later resumes by sending a new A2A message into the held context — same mechanism as resuming an input-required user prompt.
This works but is semantically off (the spec says input-required means user input) and platform-specific. A documented hook or canonical pattern would let adapters converge.
Related upstream spec gap
The fundamental missing primitive (no WaitNode / ScheduleNode in OAS 26.1.0) is also worth flagging at the spec level — filed separately at oracle/agent-spec for that broader discussion. This issue is specifically about the wayflowcore implementation side: even with a spec extension, the runtime needs a hook to make it work end-to-end.
Activity
groganz commentedon May 11, 2026
Two cross-links for context:
WaitNodewith discriminatedwait_source).InputMessageNode. Feature Request: Declarative guard/skip predicate on InputMessageNode to bypass user prompt #147 wants declarative skip-on-state; this issue wants pause-on-external-event. Both push towardInputMessageNode(or a related node type) growing first-class lifecycle hooks rather than the current binary "always prompt, always wait" contract.