<WaitForEvent> - Smithers

import { WaitForEvent } from "smithers-orchestrator";

type WaitForEventProps = {
  id: string;
  event: string;
  output: z.ZodObject | Table | string;
  correlationId?: string;
  outputSchema?: z.ZodObject;
  timeoutMs?: number;
  onTimeout?: "fail" | "skip" | "continue"; // default "fail"
  async?: boolean; // unrelated downstream may proceed while pending
  skipIf?: boolean;
  dependsOn?: string[];
  needs?: Record<string, string>;
  label?: string;
  meta?: Record<string, unknown>;
  key?: string;
};

<Workflow name="deploy-watcher">
  <Sequence>
    <WaitForEvent
      id="wait-deploy"
      event="deploy.completed"
      correlationId={ctx.input.deployId}
      output={outputs.deployEvent}
      outputSchema={deployPayload}
      timeoutMs={600_000}
      onTimeout="fail"
    />
    <Task id="notify" output={outputs.summary} agent={notifier}>
      The deploy finished. Summarize the result.
    </Task>
  </Sequence>
</Workflow>

Notes

Push-based; for poll-based checks use <Task> with a compute function.
With async, dependents via dependsOn/needs still block until payload arrives.
Async waits are tracked by the smithers_external_wait_async_pending{kind="event"} gauge while pending (it rises on start, falls on completion).
A run suspended on <WaitForEvent> (status waiting-event) does not resume itself when the event is delivered out of process. Deliver it, then resume with bunx smithers-orchestrator up workflow.tsx --run-id RUN_ID --resume true. Run the CLI from the workspace root (the directory holding .smithers/) so it resolves the same smithers.db the run wrote. See the keeper-loop pattern in the CLI overview.

​Notes

Notes