Anything that runs while I am not watching needs two lists, and they are not the same list.
The first is what it may touch. Directories, accounts, endpoints. Boring, and the only thing standing between a bug and a deleted folder. Mine is shorter than I expected: two working directories, one scratch directory, read-only everywhere else. Everything I have ever regretted came from a task that quietly needed one more permission and I gave it without thinking.
The second list is what it may do when something goes wrong. Retry twice. Stop. Report the state it was in. Never, under any circumstance, start over from the beginning, because starting over is how a half-finished change becomes a half-finished change plus a duplicate.
That second list is the one nobody writes.
Why the failure policy is harder
Permission lists are static, so you can reason about them once and forget them. Failure policy is a decision tree that only gets exercised on the days everything is already going badly, which means you write it in a hurry, if at all.
The practical version I use is three lines per task: on error, retry N times; then either abort or degrade; and always emit the last known good state so a human can pick up from it. Degrade means the task publishes what it has with the gaps marked, instead of pretending everything succeeded.
The test that matters
I now deliberately break something before trusting a scheduled task. Kill the network mid-run. Make one input file unreadable. Point one endpoint at a 500. If the task retries forever, or claims success anyway, it is not ready, no matter how good the normal-path output looks.
The awkward truth is that the failure path is the product for anything unattended. The happy path is a demo; the failure path is whether you can sleep.
Top comments (0)