Octoprint: Error 500 after update

[ddjikic]

Hi, after updating OctoPrint 2 days ago and some plugins OctoPrint worked for a bit but after a restart, I am getting an error 500 and I have the following error in OctoPrint log

Traceback (most recent call last): File "/home/octoprint/OctoPrint/venv/local/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/app.py", line 1817, in wsgi_app response = self.full_dispatch_request() File "/home/octoprint/OctoPrint/venv/local/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/app.py", line 1477, in full_dispatch_request rv = self.handle_user_exception(e) File "/home/octoprint/OctoPrint/venv/local/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/app.py", line 1381, in handle_user_exception reraise(exc_type, exc_value, tb) File "/home/octoprint/OctoPrint/venv/local/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/app.py", line 1475, in full_dispatch_request rv = self.dispatch_request() File "/home/octoprint/OctoPrint/venv/local/lib/python2.7/site-packages/Flask-0.10.1-py2.7.egg/flask/app.py", line 1461, in dispatch_request return self.view_functions[rule.endpoint](**req.view_args) File "/home/octoprint/OctoPrint/venv/local/lib/python2.7/site-packages/octoprint/server/views.py", line 413, in index response = default_view() File "/home/octoprint/OctoPrint/venv/local/lib/python2.7/site-packages/octoprint/server/views.py", line 385, in default_view return preemptively_cached() File "/home/octoprint/OctoPrint/venv/local/lib/python2.7/site-packages/octoprint/server/util/flask.py", line 886, in decorated_function cache.record(data, unless=unless) File "/home/octoprint/OctoPrint/venv/local/lib/python2.7/site-packages/octoprint/server/util/flask.py", line 752, in record self.add_data(root, entry_data) File "/home/octoprint/OctoPrint/venv/local/lib/python2.7/site-packages/octoprint/server/util/flask.py", line 848, in add_data cache_data[root] = [] TypeError: 'str' object does not support item assignment 2018-08-09 00:29:40,338 - tornado.access - ERROR - 500 GET / (192.168.1.6) 27.00ms

I have OrangePi One as hardware

[GitIssueBot]

Hi @ddjikic,

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 - that can be found at discourse.octoprint.org. Go there for any kind of issues with network connectivity, webcam functionality, printer detection or any other kind of such support requests or general questions.

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 2018-08-23 01:20 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.

[St007]

I have similar issue. Seems like Octoprint uses cache and cache is broken after hard reset.

[St007]

I was right. Quick solution delete folder /home/[your_user_name]/.octoprint/data
Then restart Octoprint. It works for me.

[GitIssueBot]

Since apparently some of the required information is still missing, I'm closing this now, sorry. Feel free to request a reopen of this or create a new issue once you can provide all required information.
This is nothing personal. Thank you for your collaboration.

[Udo]

Thank you @St007 for being helpful. To expand on your solution, it is not necessary to remove the entire folder (along with your settings and such). It's sufficient to delete the file

.octoprint/data/preemptive_cache_config.yaml

and then restart the server. Given OctoPrint's propensity for fucking up its own cache and then mishandling the result, I added the command to remove this file to my Pi's startup script to run before OctoPrint.

[foosel]

I added the command to remove this file to my Pi's startup script to run before OctoPrint

Alternatively you could of course also just disable the preemptive cache. Whatever paddles your canoe.

Given OctoPrint's propensity for fucking up its own cache and then mishandling the result

If this is general reproducible behaviour, please open a full bug report so it can be fixed. Thank you for doing your part in making an Open Source project better for everyone!

[Udo]

@foosel it is generally reproducible, however the reason why I'm hesitant to open a full report is I'm running OctoPrint on an OrangePi Zero at the moment (and the reference platform is the Raspberry Pi, right?), plus as far as I can tell this only happens after a power outage, and it looks to me (being a Python noob) like OctoPrint uses a 3rd-party caching solution which would probably be the more appropriate place to file a report. Given these reasons, I'm fine with just deleting the cache on reboot and advising others to do the same.

Alternatively you could of course also just disable the preemptive cache. Whatever paddles your canoe.

It's not about self-styled paddling so much as it is about not having known that the option existed ;)

[foosel]

Given these reasons, I'm fine with just deleting the cache on reboot and advising others to do the same.

Then maybe word such advising comments a bit differently next time, because the way you did certainly made it sound differently and slightly more on the side of "this software SUCKS!" than "I'm having some issues here that might be related to my environment or third party dependencies and I'm working around them like this" ;)

[Udo]

I take issue with this. At no point did I even imply that OctoPrint sucks. What did frustrate me was the way this issue was handled. Even though the info provided by @St007 was clearly enough to repro, and they later came back and submitted a solution themselves, you still chose to passive-aggressively close this as though it was nonsense. I apologize for letting this frustration shine through in a way that I now regret - the truth is that you and me both should have been more charitable in this thread.

As far as technical grounds go, I do think it's a bug that the cache doesn't recognize when it corrupts itself. This is not inherently OctoPrint's fault because I believe it's a generic caching component (please correct me if that's wrong). I don't know enough of the internals to make a judgement about whether OctoPrint could even in theory catch this misbehavior. If this is an option, I'd like to make a case for doing just that, even though I don't actually have the data to back up this hypothesis: it seems very likely to me that OctoPrint is primarily being run on unreliable SoCs that can and often do lose power without performing an orderly shutdown. It's thus likely that this cache corruption can in principle also occur on Raspberry devices. To users this then presents as an inability to start up with no visible indication on the web UI on what the issue may be, and it's something that can only be fixed by those willing and able to log in via terminal, search for the issue, and then take the right action. I argue that this is likely to happen to more people, you'll just never find out about the majority of these cases.

[foosel]

you still chose to passive-aggressively close this as though it was nonsense

No. The bot closed this since the OP didn't provide the required information in order to even start looking into this. No logs, no further details on reproduction steps, nothing. I wish I could run after this kind of data on every single ticket that gets opened, but that simply stopped being feasible a while ago. Drive by tickets without data to analyse them cannot be looked into, so it doesn't make sense to leave them open.

I'm happy to look into bugs when I get the data necessary to reproduce them or at the very least get a rough idea of where to start. What I simply am not in a position to do at all anymore is to try to hunt down information on possible bugs reported half-heartedly in drive by tickets that might just as well be the result of environmental factors (read: people corrupting their cards by yanking power, worn out SDs, bad power supplies, etc). Not only is it going to be a horribly inefficient (let alone frustrating) use of the limited development resources available to this project (read: mostly me), it would also be unfair towards people who do run into bugs, take the time to report them with the information needed to look and fix them (and also stand by to provide further data if needed).

In a nutshell: I'm happy to look into this, but I can't with the information presented so far. The only knowledge I have of such an issue even being more than a one-off is this incomplete ticket, I've never seen this problem myself nor have I heard of it at any other place. Snippy comments in the ticket by other people affected by the problem and frustrated by it won't fix it. Working with me to try to get to the bottom of this might.

[Udo]

I thought about this for a while. I understand. Thank you for being patient and taking the time to explain your stance on this. I use OctoPrint almost daily and it's an incredible tool. Thank you for making it.