aws / aws-sdk-php

Official repository of the AWS SDK for PHP (@awsforphp)
http://aws.amazon.com/sdkforphp
Apache License 2.0
6.04k stars 1.23k forks source link

Aws SQS: VisibilityTimeout value is zero and type is string instead integer #2893

Closed nepos87 closed 8 months ago

nepos87 commented 9 months ago

Describe the bug

Using Laravel 5.5 and processing a job with AWS Sqs, only if I have an error during processing, the queue returns the following error message:

_ErrorException: The provided type for VisibilityTimeout value was string. The modeled type is integer. in C:\Users\Win\publichtml\project\vendor\aws\aws-sdk-php\src\QueryCompatibleInputMiddleware.php:173

In particular, within the Laravel SqsJob.php file, in the following function, the variable $delay is equal to 0 (i.e. it arrives with a value of zero and does not take the default one in brackets) but with a string data type instead of an integer:

public function release($delay = 0)
     {
         echo gettype($delay); // string instead integer

         parent::release($delay);

         $this->sqs->changeMessageVisibility([
             'QueueUrl' => $this->queue,
             'ReceiptHandle' => $this->job['ReceiptHandle'],
             'VisibilityTimeout' => $delay,
         ]);
     }

But within the aws control panel the queue is set to the default value of 30 seconds in Visibility Timeout. Despite this, the $delay parameter in function arrives with a value of zero and in string format instead of integer.

Expected Behavior

The value of $delay must be 30 seconds and of type integer

Current Behavior

The value of $delay has a value of zero and of type string

Reproduction Steps

When a job fails

Possible Solution

public function release($delay = 0)
     {
         echo gettype($delay); // string
         $delay = (int) $delay;
         echo gettype($delay); // integer

         parent::release($delay);

         $this->sqs->changeMessageVisibility([
             'QueueUrl' => $this->queue,
             'ReceiptHandle' => $this->job['ReceiptHandle'],
             'VisibilityTimeout' => $delay,
         ]);
     }

Additional Information/Context

No response

SDK version used

aws-sdk-php: 3.300.11 aws-sdk-php-laravel: 3.8.1

Environment details (Version of PHP (php -v)? OS name and version, etc.)

PHP 7.4 - Laravel 5.5

nepos87 commented 8 months ago

I did several tests with different versions of aws-sdk-php and discovered that the bug appears from version 3.285.1. Before this version (for example in 3.285.0) the bug does not occur. Can this problem be solved? Thank you

stobrien89 commented 8 months ago

Hi @nepos87,

Sorry to hear about the issues. Could you point me to the exact location of the SqsJob.php file?

Recently, SQS migrated their protocol from query to json. What we discovered in that process is that (by happenstance via a mistake in one of our tests) is that because the params were all built into/parsed out of a query string, SQS would accept string values for parameters modeled as ints. This however does not work with json protocol services where the values are extracted from the payload.

The middleware emitting the warning you're seeing actually casts any incorrectly typed values it finds— the intent was to avoid breaking customers who were unintentionally sending strings for params modeled as ints or any other permutation of incorrectly typed scalar values.

nepos87 commented 8 months ago

Hi @stobrien89,

Thanks for the explanation. The SqsJob.php file is located here: https://github.com/laravel/framework/blob/5.5/src/Illuminate/Queue/Jobs/SqsJob.php

stobrien89 commented 8 months ago

Hi @nepos87,

Thanks for the clarification. The fix would need to come from the laravel side, since it appears they're sending an incorrect type. Alternatively, you could pin your SDK version to <=3.285.0 which is the last release that SQS used query protocol, but this is not recommended.

github-actions[bot] commented 8 months ago

This issue is now closed. Comments on closed issues are hard for our team to see. If you need more assistance, please open a new issue that references this one.