Hatchet vs Temporal

Hatchet

A durable task waits for a keyed event without holding a worker slot, and resumes from its event log after a restart, in Python, TypeScript, Go or Ruby. Hatchet supplies only the pause and resume. It has no approver inbox, notification channel or record of who answered, and its MCP server cannot push the event.

Temporal

Waits of any length with a timeout survive worker restarts and deploys. No reviewer inbox, notifications or routing, so the human side is all your code.

Hatchet

1. Put the approval wait in a durable task, and keep API calls, database reads and random values in child tasks, because the code between checkpoints is replayed
2. Add a sleep condition in the same or group as the event condition to set a deadline, and treat the sleep firing first as a timeout
3. Give the event a scope and the wait a lookback window when the answer can arrive before the wait starts. Both must be set together
4. Filter with a CEL expression such as input.user_id == '1234' so one approval key cannot resume another request's task
5. Push the answer with the SDK's event push or POST /api/v1/tenants/{tenant}/events. The MCP server has no tool for it
6. Grant the MCP server one profile with hatchet mcp auth --grant <profile>. It refuses profiles that were not granted

Temporal

1. Put the decision in a typed Signal payload (approver, decision, comments, timestamp) instead of a bare boolean
2. Always wait with a timeout and treat the timeout path as a rejection or an escalation on purpose
3. Use the workflow ID as the approval ID, so the reviewer's tool only needs one value to send the Signal
4. Use an Update instead of a Signal when the approver's tool needs an acknowledgement back
5. Expect ResourceExhausted under load and let the SDK retry it, since signals are throttled last