Open
Description
We recently upgraded a Rails app from 3.20.0
to 3.21.0
and began seeing all of our writes/file creation calls to AWS S3 failing with a 400 error from S3s service calls:
Example exception raised from excon
client layer:
Excon::Error::BadRequest Expected(200) <=> Actual(400 Bad Request)
excon.error.response
:body => "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<Error><Code>IncompleteBody</Code><Message>You did not provide the number of bytes specified by the Content-Length HTTP header</Message><NumberBytesExpected>228</NumberBytesExpected><NumberBytesProvided>0</NumberBytesProvided><RequestId>3SG15S95XAWWA2ZA</RequestId><HostId>g0MdNHKuphyF1e5ee7zt0g/C+4RBv4eKguXKul5TPkkK3esrFfzrEgiu63uDyIgSgl9f0FhJNpo=</HostId></Error>"
I don't see any changes in fog-aws
or excon
that appears related, but confirmed upgrading to fog-aws
3.21.0
and excon
0.104.0
causes this issue for us. Apologies for not having a simpler test case/reproduction, but thought I would log an issue in case other folks encounter this problem.
Activity
geemus commentedon Oct 3, 2023
@wpeterson Thanks for the report. Are you using fog directly or through an intermediary like carrierwave? Could you share an example of how you are calling it in the vicinity of one of the errors?
A couple of guesses:
I'm not sure on either though, and could probably benefit from a bit more detail on your usage if you can share it.
wpeterson commentedon Oct 8, 2023
@geemus Thank you for looking/thinking further about this. We are using both
fog-aws
andcarrierwave
, but the usage which produces this error appears to be a direct invocation of Fog viaFog::Storage#bucket
/bucket.files.create
invocation:I've also included a redacted version of our Gemfile.lock if that's helpful (without the
fog-aws
upgrade):https://gist.github.com/wpeterson/d8785654dc8c6c1a9061eb9f9690498f
geemus commentedon Oct 11, 2023
Thanks for the extra details, just a little slow getting back to it as I'm on parental leave right now with a new baby so things are a little chaotic.
A couple of follow up questions:
The only difference between 3.20.0 and 3.21.0 should be #691. On the plus side it's a fairly constrained change, on the less plus side, it's not immediately apparent to me how/why this would cause the problem, but hopefully since it's narrow we'll be able to pin it down without too much trouble.
wpeterson commentedon Oct 11, 2023
@geemus Thanks for looking into this and for all the work that goes into open source. This isn't urgent and you shouldn't feel the need to look at this if you've got a new baby at home.
Here's a slightly redacted stack trace showing the
400
from the AWS S3 layer. You can see a request from our controller calling a helper class, which is calling a Fog layer directly:geemus commentedon Nov 17, 2023
@wpeterson Hey, finally trying to circle back to this now that I'm back to work. I strongly suspect that if you lock to that earlier fog-aws release it should avoid the issue (I wouldn't think the excon changes would be impactful for this in particular, but definitely let me know if that seems not to be the case).
geemus commentedon Nov 17, 2023
@wpeterson Thanks for the stack-trace, that is helpful. For instance, we can see that it goes to
put_object
, which is the simpler non-multipart version (and should indicate that the file is less than the chunk size).geemus commentedon Nov 17, 2023
A couple of follow up questions to help narrow this down when you get the chance:
{ retry_limit: 5, retry_interval: 1 }
to connection options fix it?Sorry I don't have a ready answer, it's kind of a weird case and definitely something that we only see through a lot of layers of indirection, so just trying to narrow things down a bit more. Thanks.
github-actions commentedon Jan 17, 2024
This issue has been marked inactive and will be closed if no further activity occurs.