Closed JollyRgrs closed 12 months ago
What version of Cura are you using, and are you using a particular plugin to communicate with Moonraker?
What version of Cura are you using, and are you using a particular plugin to communicate with Moonraker?
Sorry, I meant to include that. Currently Cura 5.5 but it happened on 5.4 as well and I believe it was working fine on 5.4, so this is why I don't think it was a change in Cura. Using Moonraker Connection 1.7.1 which was last updated back in February (the issue did not present itself until much more recently, in fact, I was still using Octoprint and Marlin back then)
To clarify, when the printer is off, Cura does properly communicate to Moonraker to turn on the switch for the printer, even when it gets the error about uploading the gcode.
Ok, I am going to attempt to reproduce this. Until then, I have made a small change that should improve the error handling when a parse error is encountered. In the off chance that this occurs due to re-entry I have added a lock to prevent that condition, so it may be worth a test.
Moonraker uses an external dependency to parse chunked uploads and it was recently updated for compatibility with Python 3.11. Its possible that this is the source of the issue. Once I am able to repro I should be able to track it down.
I'm encountering the same issue (with identical symptoms and the same error in the logs). This error happens repeatedly (1-2-3 times in a row), and then suddenly everything starts working correctly until the next occurrence. I haven't identified any consistent patterns.
I've experienced this problem with different versions of Cura (5.4.x, 5.5 beta1, 5.5.0)
It's probably worth mentioning that I tested on a version WITHOUT the latest commit. I will now update and test with it.
I believe I have tracked down the issue. The short answer is that there is a small bug in the Cura-Moonraker plugin that needs to be fixed. Below I will provide a detailed response for posterity. I'll finish by explaining why this is showing up now.
To begin, I need to provide a primer on how upload requests work. They are a type of HTTP request with a content type known as multipart/form-data
. These requests may include multiple parts in the body, where each part is separated by a boundary. The boundary must be unique, so they often consist of randomly generated characters.
This boundary is specified in the Content-Type
request header. The content type header received from the Cura-Moonraker Plugin might look like the following:
Content-Type: multipart/form-data; boundary=boundary_.oOo._ztoqtTuftFcXb+R3aGGtZjF/xypG1vK+
According to the multipart/form-data standard outlined in RFC 2388 and RFC 2046, the value for the boundary must be enclosed in double quotes if it contains characters such as a :
or /
. Indeed, when the parser attempts to extract the boundary from this header it gets truncated, resulting in a value of boundary_.oOo._ztoqtTuftFcXb+R3aGGtZjF
. This is the cause of the parsing error.
When testing with [octoprint_compat]
enabled and the Cura Octoprint plugin, the Content-Type
header looks similar to the following:
Content-Type: multipart/form-data; boundary="boundary_.oOo._yf5SooRb+x0U4Qc1j8zJF+5pwkEBi3WN"
Notice that the value for the boundary is quoted. The parser will not truncate this value if it contains a reserved character.
The solution is either to make sure that the boundary contains no reserved characters or to quote the boundary. The author of the Cura Moonraker plugin should be able to resolve this by modifying Line 466 to add quotes around the boundary. Alternatively, rather than using the boundary generated by the QT framework, the plugin could set its own boundary that does not use reserved characters.
Moonraker depends on streaming-form-data to handle upload parsing. This includes everything from the Content-Type
to the body of the request. The version of this dependency was recently bumped to add full support for Python 3.11.
The previous version used python's cgi module to parse the Content Type header. As the link states, the cgi
module is now deprecated, and it has been recommended to use the email.message to perform this instead. The cgi
module did not strictly adhere to RFC 2046, but email.message
does. In other words, the cgi
module was able to extract the full boundary from a request that did not adhere to the standard, but email.message
truncates it.
The streaming_form_data
module cannot revert back to using cgi
, as it has been deprecated in Python 3.11 and scheduled for removal in Python 3.13. For the same reasons, Moonraker cannot revert back to an older version of streaming_form_data
, it is necessary for Moonraker to fully support Python 3.11 with the release of Debian Bookworm. In addition, it is generally a good idea to adhere to standards.
One last thing, while waiting for a fix from the Cura2Moonraker plugin author you may be able to temporarily get around this issue by manually forcing a downgrade via ssh. Assuming Moonraker's environment is installed at the default location, the following commands could work:
~/moonraker-env/bin/pip install streaming_form_data==1.11.0
sudo service moonraker restart
On some systems with Python 3.11 installed the wheel will fail to build, however on others it builds despite not officially supporting 3.11.
If the downgrade does work, one thing to keep in mind is that the update manager will upgrade it again the next time it detects a change to Moonraker's dependencies.
I'll take a look at it and make the fix - publication in the Cura Marketplace will of course take 2 weeks again
Thank you for the detailed analysis and explanation of the error/problem. I have made the fix for this and have already made it available for publication on the Cura marketplace - approval is still pending.
Hotfix is now available in the Marketplace.
Hotfix is now available in the Marketplace.
I've printed a few things now and have yet to have the issue, will keep trying to see if I can get the error to come up again but so far I can't! I'll try a few more scenarios but so far I see nothing wrong.
I tried printing after waiting for the printer to turn off from idle, I tried printing before the idle timeout, I tried printing twice from Cura without closing it first. I can't recreate the issue. I'm calling this a done deal. Thanks @emtrax-ltd and @Arksine
Getting this issue as well. I've been using the same older version for months, decided to update, now i get this problem as well. 50-85% chance of getting the connection issue.
IIs there a way to roll back an update or 2 to the version i was on? As it gave consistent successful uploads on every attempt.
@DuckersMcQuack As I mentioned in your original issue, you need to update the Moonraker Connection plugin in Cura.
@DuckersMcQuack As I mentioned in your original issue, you need to update the Moonraker Connection plugin in Cura.
Oh, ok, i see an update now. Wasn't any updates at the time of checking as of 2 or 3 days ago. Unless the newest updates only appears if i reboot the pi? As i tested that as well a few days ago.
Oh, ok, i see an update now. Wasn't any updates at the time of checking as of 2 or 3 days ago. Unless the newest updates only appears if i reboot the pi? As i tested that as well a few days ago.
To be clear, it isn't Moonraker than requires an update, it is the linked Moonraker Connection plugin you are using in Cura.
What happened
If the printer has been shut down since a previous print, I cannot send a new print via Cura to Moonraker without "touching" a gcode file. If I view (I don't have to save/edit) the file in the editor or simply choose "View 3D" or if I even just delete an existing gcode file, then that is enough where I can then hit "Upload to Printer" in Cura and it works. This was not an issue in the past but I cannot be sure when it became an issue as I don't always run multiple prints before my printer is shut down.
The error I get in Cura is a network connectivity, "Bad Gateway" error. Which does not seem appropriate as it worked fine for the first print and works fine after the workaround. The error in moonraker logs is: streaming_form_data.parser.ParseFailedException: _parser.data_received failed with delimiting multipart stream into parts
Again, nothing changed, just doing "something" with existing gcode files (view in 3d, view for editing, delete, etc.) is all that is required before the next attempt simply works.
Client
Other
Browser
Other or N/A
How to reproduce
Using Cura, print an item and after completion (and some minutes have passed) the printer is powered off (smart switch), now attempt to print (upload) another file via Cura.
Additional information
Cura configuration
relevant moonraker.conf
moonraker.log relevant timestamp of error: 2023-10-29 16:50:05,755