As an API user, I can purge completed task status records
I suggest adding support for the DELETE method on this endpoint: https://pulp.readthedocs.org/en/latest/dev-guide/integration/rest-api/dispatch/task.html#listing-tasks
And require query args that limit it to final states. For example:
If a request has no query args or specifies a non-final state, the response should be a 403.
- Should this be done asynchronously? Mongo is probably real fast at dropping records, but is it fast enough? I'd start with doing it synchronously if we can't answer the questions quickly.
- Can we safely delete tasks in the "cancelled" state? How can we know that the task isn't in the process of being cancelled? Maybe we can look at the "finish_time"?
Updated by mhrivnak over 8 years ago
Based on team discussion, let's start by doing this synchronously and see how it goes.
Cancellation does not appear to set a value for finish_time, so we can't use that to determine if it's safe to delete. We will need to look more closely at what the best thing is to do. If we delete one that's in the canceled state, it's possible that a worker process is still trying to write progress updates to the task. Maybe the best thing to do is ensure that wherever a task status is updated, it's ok if the object no longer exists and the update fails.
Updated by rbarlow over 8 years ago
We have a story about adding a new state called cancel_requested that will track the time between the cancellation request and the successful cancellation of the task. I went ahead and related that story to this story.
If we did #229 first, we'd be able to avoid this problem a little bit. It may still be possible for tasks to get stuck at cancel_requested if the message is missing from the broker somehow.