EventHandlerPlugin - On Cancel, PrintFailed event incorrectly firing before PrintCancelled

[fraschetti]

What were you doing?

Canceled a print and observed the order of events sent to on_event for the EventHandlerPlugin I'm developing.

What did you expect to happen and what happened instead?

Per the documentation and comments on the issue below, I would expect PrintCancelled to occur first then PrintFailed. It is possible to differentiate a Failed event that was triggered via a Cancel if the Cancel occurs first but if the Fail occurs first, it's difficult (without buffering events and waiting) to dismiss the Failed event (assuming that's what is intended)
#1170

Actually the design is that both events fire. A cancelled print is also a failed print. First it fires the PrintCancelled event then the PrintFailed event leaving your LEDs red.

To elaborate on this a bit more: The idea is that if you cancel a print, it obviously failed, so both events fire. There also might be another reason for the print to fail however (e.g. a communication loss during the print), so there are two separate events. In a nutshell: if you see a PrintCancelled event in your plugin, ignore the PrintFailed event that follows.

It looks like depending on what command the printer is executing, the Cancelled event may come in immediately after the Failed event or it may come in much later. e.g. if the printer is responding to a command to warm a nozzle and the print is cancelled, the Failed event occurs immediately but the Cancelled event may be waiting until the command completed on the printer?

Branch & Commit or Version of OctoPrint

Observed in both:
OctoPrint 1.3.1 (master branch)
OctoPrint 1.3.2 (master branch)

Operating System running OctoPrint

OctoPi 0.13

Printer model & used firmware incl. version

Original Prusa i3 MK2
Marlin V1.0.2; Sprinter/grbl mashup for gen6

Browser and Version of Browser, Operating System running Browser

N/A

Link to octoprint.log

https://gist.github.com/fraschetti/18ea4bbb0783627b5fa1297d0a284a8b

Link to contents of terminal tab or serial.log

https://gist.github.com/fraschetti/5d96c9b70d6c7f1d7ab8af53fe44654f

Link to contents of Javascript console in the browser

N/A

Screenshot(s) or video(s) showing the problem:

N/A

I have read the FAQ.

[GitIssueBot]

Hi @fraschetti,

It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Read the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).

If you did not intend to report a bug but wanted to request a feature or brain storm about some kind of development, please take special note of the title format to use as described in the Contribution Guidelines.

Please do not abuse the bug tracker as a support forum - if you have a question or otherwise need some kind of help or support refer to the Mailinglist or the G+ Community instead of here.

Also make sure you are at the right place - this is the bug tracker of the official version of OctoPrint, not the Raspberry Pi image OctoPi nor any unbundled third party OctoPrint plugins or unofficial versions. Make sure too that you have read through the Frequently Asked Questions and searched the existing tickets for your problem - try multiple search terms please.

I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2017-04-08 18:00 UTC) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.

[foosel]

That was actually a bug... A while ago some refactoring took place to fix another issue and that messed up the order in which the events were fired. That should now be as stated in the quoted ticket again on maintenance, soon on devel and will be released this way with 1.3.3

Thanks for reporting! (that also applies to the other ticket for course :))