Workflow APIs: Run / Signal / Query / Update / Child Workflows
When to use
Use this when the user is defining or refactoring:
- workflow entrypoint shape
- signal/query/update APIs
- child workflow orchestration
- idempotency & state model
Required guidance
- Queries must be read-only.
- Signals are fire-and-forget; make handlers idempotent.
- Updates mutate with acknowledgement; describe acceptance/completion semantics.
- Keep workflow state explicit; do not use static mutable state.
Output required
Provide:
- Recommended public surface (method signatures + attributes)
- State model outline (fields + invariants)
- Idempotency approach for signals/updates
- Minimal compile-ready example
Notes
- Prefer stable, explicit task queues.
- If the SDK supports update stages, mention how to wait for admitted/accepted/completed when relevant.
Converted and distributed by TomeVault — claim your Tome and manage your conversions.