[Bug] Missing 'x-amzn-query-error' header in JSON error responses causes TypeError in AWS SDK v3

[eladYos]

Summary

When using the latest @aws-sdk/client-sqs (> v3.6), error responses from ElasticMQ can cause a runtime crash inside the AWS SDK:

TypeError: Cannot read properties of undefined (reading 'Type')

This occurs during the SDK’s internal error deserialization logic.

---

Root Cause Analysis

ElasticMQ returns a JSON error body (which is correct), but does not include the x-amzn-query-error response header (as per AWS SQS response).

The modern AWS SDK for JavaScript (v3) relies on this header as a hint to identify the error type. When the header is missing, it tries to use a fallback (for backward compatability), which eventually results in
TypeError: Cannot read properties of undefined (reading 'Type') Deserialization error: to see the raw response

🔁 Reproduction Steps

Run the following Node.js script

Requires @aws-sdk/client-sqs to be installed.

import { SQSClient, GetQueueUrlCommand } from "@aws-sdk/client-sqs";

const client = new SQSClient({
  region: "elasticmq",
  endpoint: "http://localhost:9324",
});

  try {
    // Attempt to get a queue that doesn't exist
    await client.send(
      new GetQueueUrlCommand({ QueueName: "non-existent-queue" })
    );
  } catch (err) {
      console.log("error" ,err);
  }

---

✅ Expected Behavior

The AWS SDK should throw a proper QueueDoesNotExist error that can be handled normally.

---

❌ Actual Behavior

The AWS SDK throws:

TypeError: Cannot read properties of undefined (reading 'Type')

This happens during deserialization since the x-amzn-query-error header is missing, so it cannot determine the error type correctly

[micossow]

fixed in v1.6.16