409 error when uploading file via API and print=true

[rtheil]

This is in 1.32.

I just developed a small windows program that utilizes the OctoPrint API to upload a file. I hate Slic3r, and moved to Simplify3D, but it doesn't have OctoPrint support. So now my app monitors a local dir for gcode files and as soon as it sees a new one, it uploads. The problem is that I added an option to choose whether or not you want it to "select" or "print". Select works great without issue, but when I pass print=true, it uploads the file and starts printing, then returns a 409 conflict even though there's no conflict, because the server was completely idle.

print=true is passed in the query string (GET) while the file is POST. The only reason I did it this way is because .Net WebClient class doesn't allow you to pass additional POST data when uploading a file. So if I had used POST to pass print=true, I'm not sure if it would have made a difference.

[GitIssueBot]

Hi @rtheil,

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-28 21:50 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.

[rtheil]

What were you doing?

Uploading file to OctoPrint using REST API. Submitted file via POST and either select=true or print=true in query string (GET).

What did you expect to happen?

File to upload without any error (returns 201)

What happened instead?

Received 409 Conflict error when submitting print=true, even though there's no conflict, because the server was completely idle. select=true works perfectly. Print also starts, despite 409 error.

Branch & Commit or Version of OctoPrint

1.32 stable

Printer model & used firmware incl. version

N/A

Browser and Version of Browser, Operating System running Browser

Utilizing .Net Framework WebClient to upload file using REST.

Link to octoprint.log

Will include later. Extremely long print running at the moment.

Link to contents of terminal tab or serial.log

N/A

Link to contents of Javascript console in the browser

N/A

Screenshot(s) showing the problem:

N/A

I have read the FAQ.

[foosel]

Hm... I cannot reproduce this. Tried all of these via curl, all behaved as expected:

curl -F "file=@test.gcode" -H "X-Api-Key: test1234" http://localhost:5000/api/files/local
curl -F "file=@test.gcode" -F "print=true" -H "X-Api-Key: test1234" http://localhost:5000/api/files/local
curl -F "file=@test.gcode" -H "X-Api-Key: test1234" "http://localhost:5000/api/files/local?print=true"

Could you provide your exact .Net Framework WebClient call? Maybe that gives a reproduction here. The log file might also be helpful.

[rtheil]

Strange. It's confusing to me as well. Here's the code I've used to make the call.

                string url = "http://" + tIpAddress.Text + "/api/files/local";
                WebClient wc = new WebClient();

                //API KEY
                wc.Headers.Add("X-Api-Key", tApiKey.Text);

                //OTHER VALUES
                NameValueCollection nvc = new NameValueCollection();
                if (rbSelectForPrint.Checked)
                    nvc.Add("select", "true");
                if (rbStartPrint.Checked)
                    nvc.Add("print", "true");
                if (nvc.Count > 0)
                    wc.QueryString = nvc;

                //SUBMIT 
                string result = "";
                try
                {
                    byte[] ra = wc.UploadFile(url, "POST", e.FullPath);
                    result = Encoding.ASCII.GetString(ra);
                }
                catch (WebException we)
                {
                    setStatus(we.Message);
                }

wc.UploadFile causes an exception, which returns the 409 error.

I would also be happy to share my entire project to you, if that would help. It's nothing special. I was planning on sharing with the community anyway after it's done.

[foosel]

On first glance nothing looks off here... Yes, if you could share that project (or maybe just a minimal example exe), that might help. Problem is that I'd need to debug into the "offending" request, and right now I can't reproduce the same behaviour, so that's impossible.

[rtheil]

Here is my entire project. Created in VS2015.

OctoPrintUpload.zip

[foosel]

Heh, concurrent posting :)

[foosel]

Ok, I can reproduce it, and for some reason your code is not generating one upload request but actually three:

2017-04-19 18:45:39,546 - tornado.access - INFO - 201 POST /api/files/local?print=true (127.0.0.1) 3913.00ms
2017-04-19 18:45:40,575 - tornado.access - WARNING - 409 POST /api/files/local?print=true (127.0.0.1) 25.00ms
2017-04-19 18:45:41,632 - tornado.access - WARNING - 409 POST /api/files/local?print=true (127.0.0.1) 49.00ms

The first one succeeds, the two following ones don't - which makes sense, because the file is now busy printing, so overwriting it would be a bad idea.

Could it be that your "file created" event handler gets called multiple times?

[rtheil]

That's extremely helpful. I don't believe it's being called multiple times, but I will walk through it and check. I've never used the WebClient class before, so maybe it's doing something else I'm not seeing.

Where is the tornado log file written to? I'd like to monitor while testing this out.

[foosel]

Start your OctoPrint server with the --debug flag, that will write this to the normal octoprint.log

…

On Wed, 19 Apr 2017, 19:09 rtheil, ***@***.***> wrote: That's extremely helpful. I don't believe it's being called multiple times, but I will walk through it and check. I've never used the WebClient class before, so maybe it's doing something else I'm not seeing. Where is the tornado log file written to? I'd like to monitor while testing this out. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1872 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFGye2Ta6t-jqRABpKz08km1BTmuAWvks5rxj_JgaJpZM4M-H0O> .

[rtheil]

This can be closed, for sure. It took me forever to figure this out because what I didn't realize is that the FileWatcher runs those events in their own thread, so while debugging things come in in an order that is unexpected.

Sorry for wasting anyone's time, and thanks for helping me out! Putting some finishing touches on this app and I'll release to the community once it's all done.

[foosel]

No problem, glad you found the problem! Closing this then.