-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Uploads of files inside subdirectories always initially fail with a "Tahoe API error 500" #578
Comments
Is this repeatable, or just happened once? (I can't repeat with pre-existing subdirectories in a newly created magic-folder nor by copying in a tree of files to an existing folder). Also if you have the eliot logs from this failure, can you please attach them to this ticket? |
(I don't believe it is related to the download thing .. upon upload, whether the file is in a subdir or not shouldn't be very relevant -- except that the encoded snapshot |
I tried some manual tests and can't repeat -- can you confirm this always happens for you? |
I am still able to reproduce the same error -- with the same folder on two separate grids (the Tahoe-LAFS "pubgrid" and a personal/single node demo grid). I've attached below a zip archive of the "Cat Pics" test folder I'm using as well as eliot logs from both Tahoe-LAFS and Magic-Folder for each of the two instances I tried: CatPics.zip In each case, I see tahoe spewing |
When using/testing the latest Magic-Folder (
main@HEAD
, revb9b7864735d7742b3e3a8e16c94617736883bc3a
), I noticed that, if I add a new magic-folder that contains subdirectories containing files, uploads for those files-inside-subdirectories will always throw a "Tahoe API error 500" on the (first?) upload attempt (whereas files that are not inside subdirectories do not). Perhaps this is somehow related to #571? In any case, here's an example websocket/status message from where I observe the error:Judging by the timestamps in
recent
, it looks like the uploads do succeed a few seconds later so I'm wondering now whether the conditions that caused the initial 500 could/should be addressed so that the error isn't thrown in the first place; it probably(?) doesn't add much value to propagate or persist errors in status messages for errors can -- and, in this case, are -- immediately and automatically resolved without user interaction.The text was updated successfully, but these errors were encountered: