|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
praiskup commented 4 years ago | ||
frostyx commented 4 years ago
Well, it shouldn't be anymore. I've moved the code to the action dispatcher, in the first commit. | ||
praiskup commented 4 years ago Sorry, I can't even read my previous commit now :-) this version looks better .. but it still feels like we should rather deal with this inside Are you sure that | ||
frostyx commented 4 years ago
I can put it back, no problem. I just felt that updating frontend shouldn't be part of the
I am not, actually. But what is the status quo? See the commit message for detailed description, ... but If an action fails because of an exception, it is repeated over and over again and blocks the queue until it is finished. if an action ends with Now, what should be the common behavior? Since we don't have any frontend UI for actions and don't indicate users, that their actions failed, I have modified the | ||
|
||
|
||
|
||
See #652
We currently deal with action errors in two different ways. Let's
say, that we want to delete a project and shutil.rmtree
raises
OSError
because for example #636, then action is not updated
on the frontend (i.e. its result
is still WAITING
), unhandled
exception bubbles out to the action dispatcher and then the same
action is fetched again and again and blocks the action queue
until it is successfully finished.
On the other hand, action can expectedly fail and result in
ActionResult.FAILURE
, like for example in #652. Then the action
is finished with failure, thrown away and next action is popped
from the queue.
What is the difference between those two cases from the user
perspective? IMHO there is none and both should be handled the
same way. This change allows actions that resulted in FAILURE
to be processed again.
Well, this part makes it really far from obvious :-( the
action.run()
method itself is able to post FAILURE state to frontend (unless there's a traceback which prevents it from doing so). I'd much prefer to take care exceptions and failures withingaction.run()
directly, so from the outside it has absolutely clear semantics -- "call action.run()". Ideally, that method shouldn't even need to be wrapped byaction.run()
.