Closed adnweedon closed 10 months ago
Hi @adnweedon,
I wasn't able to reproduce this issue using AWS SQS, but I had a look at our validateMd5
middleware and found that we don't calculate an MD5 in SqsClient::calculateMessageAttributesMd5
for empty values anyway, resulting in a somewhat confusing error message. I've restricted our check to non-empty values in https://github.com/aws/aws-sdk-php/pull/2830, which should be available in today's release. This should unblock any other elasticmq customers experiencing this issue.
I can see that SQS skips the fields instead of returning empty lists/objects, so I adjusted our serialization accordingly.
Thanks so much for sorting this for us!!
The system I work on is written in PHP, and uses the AWS SQS client libraries to interact with SQS in production, and ElasticMQ locally. I tried updating the AWS package today, and found that on this recent release https://github.com/aws/aws-sdk-php/releases/tag/3.285.2, I started having issues. It would appear that the release is the switch over to using the new JSON protocol, which I believe that ElasticMQ supports, but seems to be the root of the problem.
If I put a log into the Aws\Sqs\SqsClient validateMd5() method, so I can inspect the message coming back off the queue to be processed, I can see that on SDK version 3.285.1, I get the following:
and then on version 3.285.2 I get:
The issue appears to be that an empty MessageAttributes key is now present, which without a corresponding MD5OfMessageAttributes key, throws a "No Attribute MD5 found" error.
The code we're using to push the messages in the first place looks like this (with no message attributes):
As the code has been working fine, and continues to work in production with the AWS API, I don't think that's the issue - it would appear that the change to using the JSON protocol with ElasticMQ has resulted in the bonus key?