Closed crwood closed 3 years ago
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 relpath
is a bit different / longer).
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 test-grid-tahoe-lafs-eliot.log test-grid-magic-folder-eliot.log demo-grid-tahoe-lafs-eliot.log demo-grid-magic-folder-eliot.log
In each case, I see tahoe spewing allmydata.interfaces.UploadUnhappinessError
(which probably coincides with the "Tahoe API error 500" messages?) but this seems unusual since, in both cases, I was connected to enough servers (as per the Tahoe-LAFS WebUI's "welcome page"). It's also unusual that only the files inside the subdirectories are throwing UploadUnhappinessError
; this doesn't happen for folders inside the top level of the Magic-Folder directory.
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 https://github.com/LeastAuthority/magic-folder/issues/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.