3.285.1 & >=3.285.2 break sending using a different SQS prefix

[williamdes]

Describe the bug

3.285.1 creates this error (Error parsing JSON: Syntax error):

   Aws\Sqs\Exception\SqsException  Error executing "SendMessage" on "http://awssqs:4777/queue/dev-sqs_payment"; AWS HTTP error: Client error: `POST http://awssqs:4777/queue/dev-sqs_name` resulted in a `400 Bad Request` response:
Bad Request
 Unable to parse error information from response - Error parsing JSON: Syntax error.

And since 3.285.2:

   Aws\Sqs\Exception\SqsException  Error executing "SendMessage" on "https://sqs.company-name.amazonaws.com"; AWS HTTP error: cURL error 6: Could not resolve host: sqs.company-name.amazonaws.com (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://sqs.company-name.amazonaws.com.

While dispatching a Laravel job locally.

The queue is configured like this:

        'sqs' => [
            'driver' => 'sqs',
            'key'    => env('SQS_CLIENT_KEY'),
            'secret' => env('SQS_CLIENT_SECRET'),
            'prefix' => env('SQS_PREFIX'),
            'queue'  => env('QUEUE_NAME_PREFIX') . 'queue',
            'region' => env('SQS_REGION'),
        ],

And the values

SQS_CLIENT_KEY=test
SQS_CLIENT_SECRET=test
SQS_REGION=company-name
SQS_PREFIX=http://awssqs:4777/queue/

You can see that SQS_PREFIX is respected by version 3.285.1 but does not work and since 3.285.2 it is ignored

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

Push my job

Current Behavior

No job pushed

Reproduction Steps

See description

Possible Solution

No response

Additional Information/Context

No response

SDK version used

3.285.2 and 3.288.1

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

PHP 8.2.25 (cli) (built: Oct 28 2024 22:11:18) (NTS)

[yenfryherrerafeliz]

Hi @williamdes, sorry to hear about your issues. SQS service migrated from query to JSON protocol. That changed was introduced in the same version you mentioned 3.285.2. After this migration the QueueUrl parameter is not considered anymore to construct the endpoint where the request will be sent to, and I think that is what is causing issues for you. You did not provide a full code example, but I guess you are building the QueueUrl parameter based on those env values there.
Right now you have a few workarounds:

- Add a custom middleware that modifies the endpoint

Assuming you have a custom server handling the requests and hence you need to use a custom endpoint

$client = new SqsClient([
    'region' => 'us-east-2',
]);
$client->getHandlerList()->appendBuild(
    function (callable $handler) {
        return function ($command, RequestInterface $request) use ($handler) {
            if (isset($command['QueueUrl'])) {
                $queueUrl = $command['QueueUrl'];
                $request = $request->withUri(
                    new \GuzzleHttp\Psr7\Uri($queueUrl)
                );
            }

            return $handler($command, $request);
        };
    }
);
$client->sendMessage([
    'QueueUrl' => 'http://customqueueurl',
    'MessageBody' => 'Test message'
]);

- Pin your version to any version below 3.285.1

- Use a custom endpoint when constructing the client:

$client = new SqsClient([
    'region' => 'us-east-2',
    'endpoint' => 'https://customendpoint',
]);

Please note that if you are using a custom server for handling the requests, it may not work as expected unless is fully compatible with how the SDK deserializer deserializes the responses.

Please let me know if that helps!

Thank you!

[williamdes]

Please note that if you are using a custom server for handling the requests, it may not work as expected unless is fully compatible with how the SDK deserializer deserializes the responses.

Good catch !

I upgraded to the latest version of https://github.com/Admiral-Piett/goaws/releases but still have the issue.
It seems they have been implementing the JSON protocol recently.
But that was not it.

Use a custom endpoint when constructing the client:

I added

'endpoint' => env('SQS_ENDPOINT'),

to the Laravel (11.x) config: https://github.com/laravel/framework/blob/3c672db23565c035903104e5329b5b32df560382/config/queue.php#L59

And it worked using the value: SQS_ENDPOINT=http://awssqs:4777/

@taylorotwell where you aware of AWS breaking the binding with the config ?
Or I am missing something ?
Is there not a lot of users using SQS hosted outside of amazon ?