2.7 KiB
2.7 KiB
Gotchas & Debugging
Start with the failing instance and step, then fetch the relevant guide before changing code or resource limits.
| Symptom or question | What to check |
|---|---|
| Step timeout or repeated failure | Sleeping and retrying for per-attempt timeout, retry policy, and non-retryable failures |
| CPU exhaustion despite a short run | Limits for active CPU budgets; increasing an elapsed-time timeout does not increase CPU capacity |
| Missing event or event timeout | Events and parameters for instance targeting, event type/payload requirements, and timeout handling |
| State disappears or branches change after resuming | Rules of Workflows for persisted step returns, deterministic names and conditionals, and awaited operations |
| Duplicate charge, write, or notification | Review the destination's idempotency guarantees and step design; retries can repeat an external operation even when its previous attempt committed |
| Instance ID collision or unexpected batch result | Workers API for creation semantics, plus limits for retention |
| Oversized results, queued instances, or missing historical data | Limits for return/event sizes, concurrency, creation rates, and retention; export required long-term results before expiry |
| Local-only failure or failing introspection test | Local development and Workflow test APIs |
| Inspect execution and cost | Metrics and analytics, Wrangler commands, and pricing |
CPU time measures active computation; waiting for network or storage I/O is elapsed time. Event waits, sleeps, and retry delays also have their own documented behavior. Check the current limits page for how these states affect concurrency and step accounting rather than treating every wait as active execution.
See README.md, configuration.md, api.md, and patterns.md.