Open Paril opened 8 months ago
Here's a SSCEE of the problem. The only requirements is that: a) all files and keynames referenced exist (except in the case of put dest files, obviously) b) the PHP script does not have write access to the destination file for the get (ie, getObject must throw an exception)
private function testBroken()
{
$bucketName = '....'; // put in your bucket here
$s3 = new Aws\S3\S3Client([
'region' => 'us-east-1',
'version' => 'latest'
]);
$get_key_name = 'files/sigs/test-put.png'; // must exist on S3
$get_save_to = 'files/sigs/test-saveas.png'; // must either not exist, or not have permission to access
try
{
// test get; this should throw
$params = [
'Bucket' => $bucketName,
'Key' => $get_key_name
];
$params['SaveAs'] = $get_save_to;
$file = $s3->getObject($params);
}
catch (Exception)
{
printf('got error, as expected\n');
}
try
{
// test put_many, this should not throw
$put_files = [
[ 'path' => 'files/sigs/test-0.png', 'key' => 'files/sigs/test-0.png' ], // source files must exist!
[ 'path' => 'files/sigs/test-1.png', 'key' => 'files/sigs/test-1.png' ] ];
$put_promises = [];
foreach ($put_files as $file)
{
$put_promises[] = $s3->putObjectAsync([
'Bucket' => $bucketName,
'Key' => $file['key'],
'ACL' => 'public-read',
'SourceFile' => $file['path']
]);
}
\GuzzleHttp\Promise\Utils::unwrap($put_promises);
printf('put success\n');
}
catch (Exception)
{
printf('got error, unexpected!!\n');
}
}
Note that the following will happen:
got error, as expected
will be logged. this is expected, obviously, as the file should not have write permissions. This is not the problem, and is expected!got error, unexpected!!
will be logged next. This is the bug. The exception, if you introspect it, will be the exception from the first get
failure and not related to the put
at all.If you remove the getObject
call entirely, the put
s will succeed.
Hi @Paril, thanks for reporting this. I was able to reproduce the issue by following your example. I am working on root causing it. I will provide updates as soon as possible.
Thanks!
Hi @Paril, we are still working on getting this fixed; however, in the meantime, a workaround would be to provide a custom http handler in the client as following:
$s3 = new S3Client([
'region' => getenv('TEST_REGION'),
'version' => 'latest',
'http_handler' => function (RequestInterface $request, $options) {
return \Aws\default_http_handler()($request, $options);
}
]);
I will provide more updates here, once we get this fixed.
Thanks!
Describe the bug
We're running a small test suite of things after upgrading our aging S3 client library to this one. One of the things we've done is added asynchronous/parallel uploading with
putObjectAsync
, but our usages ofgetObject
only ever fetch one object so we have that synchronous.If we force a failure condition from
getObject
(such as fetching an object that doesn't exist), the next calls to any Promise-based functions throw a 'ghost' exception of the synchronous call, despite it not relating to any of the promises we're waiting on.Expected Behavior
No exception thrown
Current Behavior
Exceptions thrown. Here's the exception log we're dealing with;
Reproduction Steps
In our runTask, we're running two separate tasks: one is a get, which tries to get a file into a path it does not have permissions to write to,
test-get-successv2.png
. This is supposed to fail, and is failing as expected.However, the next task is then supposed to do an unrelated
put_many
to paths that, when executed without the get having run prior, succeed with no errors. It is only when running with theget
that theput_many
then throws exceptions.Our "get" function is very simple, only running this (with error checking, etc):
return $this->s3->getObject($params);
Our
put_many
is a bit more complex, but all it really does is do several$this->s3->putObjectAsync
's, puts them in an array, and then\GuzzleHttp\Promise\Utils::unwrap
's them. That unwrap is what's throwing the ghost exception from the priorgetObject
.Note that the paths in the exception were not sent at all to
put_many
.Possible Solution
No response
Additional Information/Context
No response
SDK version used
3.275.1
Environment details (Version of PHP (
php -v
)? OS name and version, etc.)PHP 8.0, rest should be unrelated