TypeError: Cannot read property 'Code' of undefined

[radford-for-smpte]

Describe the bug

Periodically, when an SqsClient sends a ReceiveMessageCommand I receive:

TypeError: Cannot read property 'Code' of undefined
    at loadQueryErrorCode (/home/me/node_modules/@aws-sdk/client-sqs/dist/cjs/protocols/Aws_query.js:2583:20)
    at deserializeAws_queryReceiveMessageCommandError (/home/me/node_modules/@aws-sdk/client-sqs/dist/cjs/protocols/Aws_query.js:941:17)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at async /home/me/node_modules/@aws-sdk/middleware-serde/dist/cjs/deserializerMiddleware.js:6:20
    at async /home/me/node_modules/@aws-sdk/middleware-signing/dist/cjs/middleware.js:11:20
    at async StandardRetryStrategy.retry (/home/me/node_modules/@aws-sdk/middleware-retry/dist/cjs/StandardRetryStrategy.js:51:46)
    at async /home/me/node_modules/@aws-sdk/middleware-sdk-sqs/dist/cjs/receive-message.js:7:22
    at async /home/me/node_modules/@aws-sdk/middleware-logger/dist/cjs/loggerMiddleware.js:6:22

Your environment

SDK version number

@aws-sdk/client-sqs": "^3.31.0

Is the issue in the browser/Node.js/ReactNative?

Node.js

Details of the browser/Node.js/ReactNative version

v14.17.5

Steps to reproduce

Please share code or minimal repo, and steps to reproduce the behavior.

      await sqsClient.send(new ReceiveMessageCommand({
        MaxNumberOfMessages: 1,
        QueueUrl: url,
        VisibilityTimeout: 20,
        WaitTimeSeconds: 2,
      }))

Observed behavior

See stack trace above

Expected behavior

Screenshots

Additional context

[stavenko]

This code also fails with Same error:

  const client = new Route53Client({ credentials: ctx.awsCredentials });
  const hostedZoneId = await findZoneId(
    ctx.awsCredentials,
    buildDnsZoneName(ctx)
  );

  const command = new ChangeTagsForResourceCommand({
    ResourceId: hostedZoneId,
    ResourceType: "hostedzone",
    AddTags: hostedZoneTags(ctx),
  });
  const res = await client.send(command); //  TypeError: Cannot read property 'Code' of undefined at loadRestXmlErrorCode  (/my-shiny-project/node_modules/@aws-sdk/client-route-53/protocols/Aws_restXml.ts:10446:18)**

After diving into some debugging, I found out, that actual error is httpStatusError: 400.

And this is data, passed to a constructor of HttpRequest:

{
  "protocol": "https:",
  "hostname": "route53.amazonaws.com",
  "method": "POST",
  "headers": { "content-type": "application/xml" },
  "path": "/2013-04-01/tags/hostedzone/%2Fhostedzone%2FSomeVerySecretZoneId",
  "body": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><ChangeTagsForResourceRequest xmlns=\"https://route53.amazonaws.com/doc/2013-04-01/\"><AddTags><Tag><Key>Project</Key><Value>cc/backend3d</Value></Tag><Tag><Key>Role</Key><Value>shiny-project/infra</Value></Tag><Tag><Key>Owner</Key><Value>cc</Value></Tag><Tag><Key>Requestor</Key><Value>cc</Value></Tag><Tag><Key>Environment</Key><Value>dev</Value></Tag><Tag><Key>Team</Key><Value>shiny-project</Value></Tag></AddTags></ChangeTagsForResourceRequest>"
}

[shayonj]

Ran into this as well. Is there a temporary mitigation known?

Happens on 3.41.0, as well.

UPDATE: I fixed the issue i was having. Increasing the WaitTimeSeconds resolved it. I reckon the localstack instance I was running it with, just got overloaded with the new SDK.

[vudh1]

Hi @radford-for-smpte, thanks for reaching out. I'm not able to reproduce the issue. Can you check if you are still experiencing this with the latest SDK version 3.42.0?

[github-actions]

This issue has not received a response in 1 week. If you still think there is a problem, please leave a comment to avoid the issue from automatically closing.

[shumphrey]

I also see this issue.
I tracked it down to how aws-sdk-v3 is handling error responses from the server.
In my case, the server is localstack, if localstack returns an error, aws-sdk-v3 errors on rendering the error, thereby masking the real error.

For example if you try and delete a message on a queue for a message that doesn't exist, the server responds with something like "invalid receipt handle", and aws-sdk-v3 insteads shows the Cannot read property 'Code' of undefined error

[fluggo]

I received this error today during the outage, when handling a response from the Redshift API. The source is this generated function:

const loadQueryErrorCode = (output, data) => {
    if (data.Error.Code !== undefined) {
        return data.Error.Code;
    }
    if (output.statusCode == 404) {
        return "NotFound";
    }
    return "";
};

...which is run to try to determine the error code to reply with. In this case, the response code was 503 and the body was empty, so the data parameter to the above function was an empty object.

Edit: Ultimately the error appears to be in this code which generates the loadQueryErrorCode function:

// Attempt to fetch the error code from the specific location.
String errorCodeLocation = getErrorBodyLocation(context, "data") + ".Code";
writer.openBlock("if ($L !== undefined) {", "}", errorCodeLocation, () -> {
    writer.write("return $L;", errorCodeLocation);
});

This function needs to first check if the part before ".Code" exists.

[eliellis]

We are also seeing this error while using the SQS client and have traced the issue back to the same location as @fluggo mentioned. This is not while using localstack either, this is seen intermittently while calling the AWS SQS API.

[Cleanshooter]

bump - same issue, please fix

[ronit-chakraborty]

Running into the same error while sending emails with the SES client, the error is masking our efforts to discover the underlying cause.

[xiaoxinghu]

same issue for me with SES client. Does anyone know any workaround for now? Just want to see what the real issue is (the underlying error messages being masked by this error).

[eliellis]

same issue for me with SES client. Does anyone know any workaround for now? Just want to see what the real issue is (the underlying error messages being masked by this error).

I would suggest opening a ticket with AWS directly, making sure to directly reference this issue to get more attention on it. We’ve had one open for some time now. Our “hit it with a mallet” remedy has just been to wrap any call to the client in an external try/catch and retry indefinitely…Not great, but it works™️. Still no way of identifying the underlying issue.

[mjgp2]

Here is the diff that solved my problem:

diff --git a/node_modules/@aws-sdk/client-sns/dist-cjs/protocols/Aws_query.js b/node_modules/@aws-sdk/client-sns/dist-cjs/protocols/Aws_query.js
index 1b53c3e..3239ee6 100644
--- a/node_modules/@aws-sdk/client-sns/dist-cjs/protocols/Aws_query.js
+++ b/node_modules/@aws-sdk/client-sns/dist-cjs/protocols/Aws_query.js
@@ -4352,7 +4352,7 @@ const buildFormUrlencodedString = (formEntries) => Object.entries(formEntries)
     .map(([key, value]) => smithy_client_1.extendedEncodeURIComponent(key) + "=" + smithy_client_1.extendedEncodeURIComponent(value))
     .join("&");
 const loadQueryErrorCode = (output, data) => {
-    if (data.Error.Code !== undefined) {
+    if (data.Error?.Code !== undefined) {
         return data.Error.Code;
     }
     if (output.statusCode == 404) {

[kuhe]

I'm having trouble reproducing this error on the latest version.

I tried the Route53 and SQS code snippets provided, inducing errors by using incorrect values for hosted zone id, queue url, message receipt handle etc.

In my test cases the server response comes through with the correct description of the errors, for example No hosted zone found with ID for R53 or ReceiptHandle being invalid for SQS.

[boardofchris]

Just hit this issue with "@aws-sdk/client-sqs": "3.48.0". This was with a real AWS SQS with this command new SendMessageCommand({ QueueUrl, MessageBody }).

This is the first time I've noticed the error in the logs from 1000's of queue messages. It isn't reproducible with the same inputs - the same message sent again is successful.

[krosenk729]

We are also hitting this exact message. same as above, it is random and not reproducible. what can we do to help troubleshoot the issue?

"TypeError: Cannot read property 'Code' of undefined
    at loadQueryErrorCode (node_modules/@aws-sdk/client-sqs/dist-cjs/protocols/Aws_query.js:2581:20)
    at deserializeAws_querySendMessageCommandError (node_modules/@aws-sdk/client-sqs/dist-cjs/protocols/Aws_query.js:1024:17)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at node_modules/@aws-sdk/middleware-serde/dist-cjs/deserializerMiddleware.js:6:20
    at node_modules/@aws-sdk/middleware-signing/dist-cjs/middleware.js:11:20
    at StandardRetryStrategy.retry (node_modules/@aws-sdk/middleware-retry/dist-cjs/StandardRetryStrategy.js:51:46)
    at node_modules/@aws-sdk/middleware-sdk-sqs/dist-cjs/send-message.js:6:18
    at node_modules/@aws-sdk/middleware-logger/dist-cjs/loggerMiddleware.js:6:22

[Matthew-Myers]

I'm also hitting the same issue. Seems like the cause for me was sending too large of a message. I could reliably get this error when sending a massive message to SNS

[batflarrow]

I keep hitting this error with my SQS client for the ReceiveMessageCommand it's random and not reproducible, is there something that can be done from our side to resolve this?

[talha5389]

I am also getting error with 3.150.0 of @aws-sdk/client-sqs

[dhay]

I receive this error when sending a payload to PutMetricsData in the Cloudwatch client. The server returns a 413 response code and an empty data object, so the "Code" value is not present.

[markwainwright]

We've been seeing this periodically in production from the SNS client. I can intermittently reproduce it by making a large number of requests in quick succession (real endpoint, not localstack).

I tracked it down to the same location as @fluggo. In my case though the root cause is a 408 Request Timeout response from the AWS endpoint with an empty body.

Seems that the clients need to be updated to handle empty response bodies.

Stack trace:

TypeError: Cannot read properties of undefined (reading 'Code')
    at loadQueryErrorCode (/redacted/node_modules/@aws-sdk/client-sns/dist-cjs/protocols/Aws_query.js:5711:20)
    at deserializeAws_queryPublishCommandError (/redacted/node_modules/@aws-sdk/client-sns/dist-cjs/protocols/Aws_query.js:2545:17)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async /redacted/node_modules/@aws-sdk/middleware-serde/dist-cjs/deserializerMiddleware.js:6:20
    at async /redacted/node_modules/@aws-sdk/middleware-signing/dist-cjs/middleware.js:11:20
    at async StandardRetryStrategy.retry (/redacted/node_modules/@aws-sdk/middleware-retry/dist-cjs/StandardRetryStrategy.js:51:46)
    at async /redacted/node_modules/@aws-sdk/middleware-logger/dist-cjs/loggerMiddleware.js:6:22
    ...

[eliellis]

I would suggest opening a ticket with AWS directly, making sure to directly reference this issues to get more attention on it. We’ve had one open for some time now. Our “hit it with a mallet” remedy has just been to wrap any call to the client in an external try/catch and retry indefinitely…Not great, but it works™️.

On Tue, Mar 29, 2022 at 11:31 PM Xiaoxing Hu ***@***.***> wrote: same issue for me with SES client. Does anyone know any workaround for now? Just want to see what's the real issue. — Reply to this email directly, view it on GitHub <#2861 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJXK2WKWRGL73PTIHIY6CDVCPDIXANCNFSM5FGQQJSQ> . You are receiving this because you commented.Message ID: ***@***.***>

-- —Eli

[SishaarRao]

Encountered this with "@aws-sdk/client-sqs": "^3.43.0", was not able to reproduce

[raimille1]

Just ran into this using: "^3.245.0"

[kuhe]

PR #4367 adds the suggested ?.Code checked access operator. These TypeErrors should now fall through to the default error handler and give more information.

The versioning containing it is https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.261.0

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.