retoorandClaude Sonnet 5.5
ec9c471780
Feed panes in the multiplexer (vpane_* control commands, main-vertical layout, header row), src/orch (board, panel, formatter, transport, CAP adapter), Agent observer and cancel flag, supervision (idle warn/cancel, user close cancels, soft then hard stop), CAP answers collected through the spill path. Research archived under background-work-limits. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2.4 KiB
2.4 KiB
Understanding the 4 types of Activity timeouts in Temporal
Metadata
| Field | Value |
|---|---|
| Institute | Molodetz Institute — Research & Retrieval Division |
| Subject | background-work-limits |
| Document type | Source Dossier |
| Tier | 1 |
| Source title | Understanding the 4 types of Activity timeouts in Temporal |
| Source URL | https://temporal.io/blog/activity-timeouts |
| Source publisher / author | Temporal Technologies |
| Source type | blog post |
| Source date (published) | Unknown — not stated |
| Date researched | 2026-10-25 |
| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
| Research method | direct page fetch |
| Confidence | High |
| Status | Active |
Summary
Temporal's explanation of the four timeouts that bound a unit of work: schedule-to-start, start-to-close, schedule-to-close and heartbeat. The reference design for detecting dead or stalled workers.
Key findings
- Start-To-Close limits one execution; 'We recommend ALWAYS setting this'; it must exceed the longest possible run; it is how a crashed worker is noticed, because the server cannot see it otherwise.
- Heartbeat limits the time between heartbeats; for long activities it detects a dead or stalled worker sooner than Start-To-Close; if no heartbeat timeout is set, recorded heartbeats are discarded.
- Schedule-To-Close limits total time including retries and is the recommended way to bound retrying rather than tweaking maximum attempts; without a limit Temporal 'will retry a failing Activity Execution for up to 10 years'.
- Schedule-To-Start limits how long a task may wait in a queue; 'This is rarely needed' - monitor the schedule-to-start latency metric instead; it does not trigger a retry.
- A timeout triggers a retry according to the retry policy and increments the attempt count.
Pros / strengths
Small, exact, and states which timeout to set and which to monitor instead.
Cons / limitations / caveats
Designed for a server with a task queue; tai has no queue between spawn and start, so schedule-to-start is moot.
Relevance to tai
Supports tai's three clocks: a wall-clock limit on every job (fork timeout 30..3600 s), a heartbeat (every event; 60 s idle shows, 300 s idle cancels), and a bound on retries (none: tai does not retry sub agents automatically).
Changelog
| Date | Change |
|---|---|
| 2026-10-25 | Initial dossier created. |