On 2020-12-29 at 09:39 +0000, Nikolaus Rath wrote: > On Dec 28 2020, Ivan Shapovalov <[email protected]> wrote: > > On 2020-12-28 at 13:41 +0000, Nikolaus Rath wrote: > > > <snip> > > > > Indeed it does. I have added some proper exception logging and > > found > > the actual problem, which is — unsurprisingly — combination of user > > error, unclear system requirements and broken logging. > > Great, thanks for your help! > > Could you tell what exactly you changed to make the exception > information appear?
Sure, I'll send a PR fixing exception logging shortly. > > <snip> > > I consider this a bug in the B2 backend (and other backends may have > the > same problem). If the backend returns an exception from write(), this > should not result in a second exception from close(). Either write() > should update the checksum to reflect the partial data that was > written > (thus eliminating the checksum error on upload), or perhaps it should > set a flag that this object should not be uploaded at all on close. > > https://github.com/s3ql/s3ql/issues/228 > As far as I remember from my brief digging, all backends are implemented similarly in this regard. Any exception in ObjectW.write() will bubble up through do_write() in BlockCache._do_upload() to AbstractBackend.perform_write(), which holds the ObjectW as a context manager, and exit it, thus calling ObjectW.close(). > > <snip> > > > > I guess this was causing the 400 as well, because we were sending > > the > > temporary file including the last partial write, but the locally > > computed hash did not include it. > > Exactly. > > > There is still a problem of getting the dugong.StateError instead > > of a > > 400. I don't know why it started giving me this, even after rolling > > back all the tentative patches. Though I'm sure it will be > > something > > trivial. > > My guess is that dugong is expecting more data in the request (thus > the request is not considered complete and there is no response that > could be read). However, looking at the code, I do not immediately > see > why this would be the case. Yeah, me neither. > Best, > -Nikolaus Thanks, -- Ivan Shapovalov / intelfx / -- You received this message because you are subscribed to the Google Groups "s3ql" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/s3ql/5620a015df04eac8ddae018ec82b54dd8b7a03fe.camel%40intelfx.name.
signature.asc
Description: This is a digitally signed message part
