We surely want to be able to cancel submitted tasks, which stops the queue from scheduling remaining retries and inform worker that task is failed, hence, they can kill their process (this happens through RabbitMQ exchanges, refer to example use cases).

As for the two API calls, I see:
 * `/task/<task-id>/cancel` as something called by task graph scheduler, when a user cancels the entire graph, and
 * `/task/<task-id>/failed`, as something called by a worker, when the worker determines that the task definition is invalid. Or that it is formulated in a way that means it cannot possibly ever succeed.

In both cases the queue will resolve tasks as failed, but the `reason` given in the task status structure differs...