Bug #11682
closed[API] Deleting container request doesn't cancel containers
100%
Description
Deleting a container request record should have the same effect as setting priority to 0: it should reevaluate the priority of the container and possible cancel it. Currently that doesn't happen.
Updated by Tom Morris over 7 years ago
- Assigned To set to Radhika Chippada
- Target version set to 2017-07-19 sprint
Updated by Tom Clegg over 7 years ago
Deleting a CR should invoke the same hook that runs when priority changes, so (if a container is assigned and the deleted CR had the highest priority of any CR for the assigned container) the container's priority gets updated accordingly.
Updated by Radhika Chippada over 7 years ago
- Status changed from New to In Progress
Updated by Tom Clegg over 7 years ago
Would it work just as well to use the existing container and CR called "running" instead of adding new fixtures?
I like the approach of calling update_attributes!(priority: 0) but this seems more like a model concern than a controller concern. Does it work to call self.update_attributes!() in a before_destroy hook on the model instead of the controller? Otherwise, perhaps we just have to call update_priority in an after_destroy (or before_destroy?) hook, and add "...or !persisted?" to the list of conditions in update_priority that trigger an update.
Updated by Radhika Chippada over 7 years ago
Branch 11682-delete-container-request @ 27b7b66
I like the approach of calling update_attributes!(priority: 0) but this seems more like a model concern than a controller concern. Does it work to call self.update_attributes!() in a before_destroy hook on the model instead of the controller? ...
Good suggestion. Changed to use a before_destroy filter
Would it work just as well to use the existing container and CR called "running" instead of adding new fixtures?
Test works (worked) with the fixture "running" as well. However, if we were to add any other fixtures with priority>0 using the same container_uuid in future, then the test would fail. We could delete all such container_requests before checking priority in the test. However, I think it would be nice to have the test be independent. I can change the test to use "running" if you prefer to.
Updated by Tom Clegg over 7 years ago
Thanks. I think this version looks cleaner.
This test looks like it can/should be done as a unit test -- calling "post :destroy" doesn't add any value compared to calling c.destroy directly, does it?
Can you add a test that destroys a container_request that has priority>0 and state=Final? That should be possible, but I'm suspicious it might fail with "can't update priority when state=Final".
Updated by Radhika Chippada over 7 years ago
@ commit:27027c4
Thanks. I think this version looks cleaner.
It sure does. Thanks.
This test looks like it can/should be done as a unit test -- calling "post :destroy" doesn't add any value compared to calling c.destroy directly, does it?
You are right. Replaced the controller test with a unit test.
Can you add a test that destroys a container_request that has priority>0 and state=Final? That should be possible, but I'm suspicious it might fail with "can't update priority when state=Final".
Thanks for noticing the bug I introduced when moving the code around. Corrected the before_destroy implementation and added a unit test to delete a container_request in Final state.
Updated by Radhika Chippada over 7 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Applied in changeset arvados|commit:3a5b003b5cf784e96799d8ddadc939834620fd34.