Deprecating stop_task: A Discussion

Since it’s inception, stop_task (in my opinion) has sat in a rather weird place:

• It has current and total arguments, neither of which matter because the progress is discarded for the default 100% once it “errors”.
• The example use case shows catching an error, sending task metadata that the task has failed, and then ignoring the result
  • Is this not the same as simply letting the error propagate to the frontend?
  • If you have a desire to have a custom exception message, why not simply raise Exception(exception_message_string) or the like instead?
• stop_task doesn’t actually stop the task on it’s own, you HAVE to raise an exception anyways for it to stop. All stop_task does is tell any currently running bars to stop listening.
• An edge case presents itself in websocket progress bars if the task “failure” message fails to get through. The post-run handler will only receive information related to the “Ignored result”, and will cause any progress bars that are listening to display an incorrect error if it fails to properly disconnect from the stop_task call (see #54).
  • This can be fixed with making the Ignore exception raise inside of stop_task, and pass it metadata that the post-run handler can try to decipher whether the Ignore exception means “Ignore”, or “We actually mean FAILURE but we’d rather do it the hard way instead”. This would require having to type-check every result that passes through the handler, and if it’s an Ignore exception, look to see if specific metadata is present to then change the state and result to send to the progress bar. However, what’s the point of doing that vs. actually just raising the error in the first place?

stop_task may have been a great idea at the time, but I feel that it’s rather antiquated for the reasons listed above. Obviously, this would be a breaking change, so that must be taken into consideration. @czue @OmarWKH thoughts?

[eeintech]

Another thought that came to my mind, stop_task may only makes sense if a start_task method existed. However, I don’t think it should be the focus of the celery-progress utility, instead make it as simple as possible to manage the progress/status of a running task. If the two start and end points (creating/activating and ending/killing) stay true to Celery, then one should have no problem implementing those using Celery’s documentation.

[EJH2]

If we choose to keep stop_task, the only suitable solution that comes to mind would be something like this:

def stop_task(exc):
    raise (exc if isinstance(exc, Exception) else Exception(exc))

This would have the exact same effect as the what the previous implementation aimed to accomplish, with the caveat that the bar would still go to 100%. In order for us to maintain the current state of the progress bar vs filling it completely, we would have to make changes to the client-side JavaScript to somehow interpret that from the response, and we would have to modify how Progress.get_info sets the progress state for “completed” tasks to detect failures vs. successes, as right now both states just return the “completed” task state.

In the end, all of this is just extra work to offer a crutch for actually just raising the error yourself. Heck, it even takes more characters to type stop_task(exc=exc) instead of raise exc. ConsoleProgressRecorder’s method doesn’t even do anything! While I understand the valid concern for whether or not we should cater to entry-level programmers, I would think that if they’ve somehow managed to set up a Django webserver that requires progress bars, they would have at some point come across the try/except logic and exception raising.