OctoPrint / OctoPrint

OctoPrint is the snappy web interface for your 3D printer!
https://octoprint.org
GNU Affero General Public License v3.0
8.23k stars 1.67k forks source link

strange behavior with extension_tree hook files visibility in file list #5049

Open jneilliii opened 1 month ago

jneilliii commented 1 month ago

The problem

With a plugin like Upload Anything, uploading a file doesn't show in file list after an OctoPrint restart, but shows up after pressing the refresh button in file list? Possibly related to the type of upload being model instead of machinecode?

Did the issue persist even in safe mode?

I cannot test this issue in safe mode (state why below)

If you could not test in safe mode, please state why ("currently printing" is NOT an excuse!)

need a plugin that implements an extension_tree

Version of OctoPrint

1.10.2

Operating system running OctoPrint

Windows 10

Printer model & used firmware incl. version

Virtual Printer

Browser and version of browser, operating system running browser

Google Chrome Version 127.0.6533.100 (Official Build) (64-bit)

Checklist of files to include below

Additional information & file uploads

octoprint-systeminfo-20240814015907.zip

localhost-1723615235588.log

video below shows me open settings dialog, but it was the pressing of the refresh button that got the file to show up after further testing.

https://github.com/user-attachments/assets/cbc13d8d-e3ff-4b09-b4c7-ff25c115a898

Long discussion on Discord about it with @paukstelis: https://discord.com/channels/704958479194128507/708230241285439518/1272736205867319379

foosel commented 3 weeks ago

That issue was a combination of two factors.

We have some aggressive caching in the file storage so that file lists don't cost too much. The problem now was that due to some metadata maintenance, the cache would be filled for the first time before plugins had been fully initialized. And at least in the case of the Upload Anything plugin, that would mean it would return an empty extension list. So right after restart, the file list would be recursively cached, but without the additional extensions. And since there was now a cache, later reloads of the UI would use that instead of scanning the directories again (with the proper extension list). A forced refresh of the file list however ignores the cache, and so that would then be fixed.

I've now made sure the initial metadata check won't cause the cache to be filled, so that things should work, even if a plugin can't provide the list of supported extensions after settings access.

jneilliii commented 3 weeks ago

Thanks. We found out later that a plugin that has the extension tree set not based on settings that the files would show without issue, so definitely seemed to be specific to if the plugin accessed settings or not to build the tree.