SQS messages without attributes cannot be received

[nicosp]

Describe the bug

Message fails with: "No Attribute MD5 found. Expected ". This issue is present between 3.285.1 and at least until 3.286.2.

I downgraded to 3.285.0 and the issue was gone.

Expected Behavior

Receive the message without an exception.

Current Behavior

For some reason the MessageAttributes are set and not null but they are not an array. Note that the actual message does not have any attributes or the "MessageAttributes" property.

Reproduction Steps

Send a message without any message attributes. Try to receiveMessage.

Possible Solution

No response

Additional Information/Context

No response

SDK version used

3.285.1-3.286.2

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

PHP 8.2.12 (cli) (built: Oct 26 2023 17:23:09) (NTS) on Debian/sid

[nicosp]

An example message as received from aws cli is:

  "Messages": [
    {
      "MessageId": "285d73e9-208b-455b-b082-8569c80fc613",
      "ReceiptHandle": "285d73e9-208b-455b-b082-8569c80fc613#815c4dea-98a4-4553-bdc3-b636ff4a5cab",
      "MD5OfBody": "86677f261392ee979dc608eff901ee7d",
      "Body": "<REDACTED>"
    }
  ]
}

[stobrien89]

Hi @nicosp,

Sorry to hear about the issues. This is likely due to the SQS migration from query to json protocol— it's possible that this is exposing bad config, but very hard to tell without a code example and debug logs. Could you please provide a reproducible example and provide debug logs by adding 'debug' => true to your client configuration? Please be sure to obscure any sensitive information such as account numbers. Thanks!

[nicosp]

I think I have pinpointed the issue. We are using elasticmq for local development and when the original message does not have any MessageAttributes it sends an empty MessageAttributes array and no MD5OfMessageAttributes. This causes Sqs::calculateMessageAttributesMd5 to expect the checksum for the empty string and fails because there is no checksum in the message.

result was set to array(2) {
    ["instance"]=>
    string(32) "00000000000001d30000000000000000"
    ["data"]=>
    array(2) {
      ["Messages"]=>
      array(1) {
        [0]=>
        array(6) {
          ["MessageId"]=>
          string(36) "f6df2099-7d1a-4a87-b9f2-ab3fa4b6b09f"
          ["ReceiptHandle"]=>
          string(73) "f6df2099-7d1a-4a87-b9f2-ab3fa4b6b09f#0c6854bb-0b6a-4970-933c-1ffd79062fe0"
          ["MD5OfBody"]=>
          string(32) "8ddac628a692426e58f56d1fd99bdddb"
          ["Body"]=>
          string(174) "<REDACTED>"
          ["Attributes"]=>
          array(0) {
          }
          ["MessageAttributes"]=>
          array(0) {
          }
        }
      }
      ["@metadata"]=>
      array(4) {
        ["statusCode"]=>
        int(200)
        ["effectiveUri"]=>
        string(21) "http://localhost:9324"
        ["headers"]=>
        array(4) {
          ["server"]=>
          string(16) "pekko-http/1.0.0"
          ["date"]=>
          string(29) "Fri, 17 Nov 2023 07:24:31 GMT"
          ["content-type"]=>
          string(16) "application/json"
          ["content-length"]=>
          string(3) "453"
        }
        ["transferStats"]=>
        array(0) {
        }
      }
    }
  }

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[stobrien89]

Hi @nicosp,

Dug a bit further into this and wasn't able to reproduce this using SQS. My guess is that ElasticMq is opting to send an empty array for MessageAttributes in the absence of attributes. We return null for empty values sent to calculateMessageAttributesMd5, which makes for a confusing error message, so I've updated the last condition in our SQS validateMd5 middleware to ignore empty MessageAttributes values. This should unblock ElasticMq users who are experiencing this issue.

[nicosp]

@stobrien89 Thank you for the fix. Just a heads up that elasticmq also fixed this on their side with version 1.5.2