Skip to content

Error between Lambda and DynamoDB

0

Hello,

We create this case because from this day we have an error with our Lambda and our DynamoDB table in several accounts. Yesterday it worked and now we have an error when our Lambda need to interact with the DynamoDB table.

In general we receive a mail from AWS when something change on AWS services that we use and this time we receive nothing. Have you change anything about how it works with DynamoDB (create or update item for example) or with Lambda ? The error that we are facing is the following:

Error : SerializationException: Start of structure or map found where not expected at ProtocolLib.getErrorSchemaOrThrowBaseException (/var/runtime/node_modules/@aws-sdk/core/dist-cjs/submodules/protocols/index.js:70:67) at AwsJson1_0Protocol.handleError (/var/runtime/node_modules/@aws-sdk/core/dist-cjs/submodules/protocols/index.js:807:65) at AwsJson1_0Protocol.deserializeResponse (/var/runtime/node_modules/@aws-sdk/node_modules/@smithy/core/dist-cjs/submodules/protocols/index.js:597:24) at process.processTicksAndRejections (node:internal/process/task_queues:103:5) at async /var/runtime/node_modules/@aws-sdk/node_modules/@smithy/core/dist-cjs/submodules/schema/index.js:27:24 at async /var/runtime/node_modules/@aws-sdk/node_modules/@smithy/core/dist-cjs/index.js:119:20 at async /var/runtime/node_modules/@aws-sdk/node_modules/@smithy/core/dist-cjs/submodules/retry/index.js:172:50 at async /var/runtime/node_modules/@aws-sdk/core/dist-cjs/submodules/client/index.js:119:26 { '$fault': 'client', '$retryable': undefined, '$metadata': { httpStatusCode: 400, requestId: 'ABCD012345', extendedRequestId: undefined, cfId: undefined, attempts: 1, totalRetryDelay: 0 }, __type: 'com.amazon.coral.service#SerializationException' }

Regards

3 Answers
1

The SerializationException error you're encountering typically indicates a data format mismatch between what your Lambda function is sending to DynamoDB and what DynamoDB expects. This is a client-side error (indicated by the 400 status code) rather than a service-level change from AWS.

Common causes for this error include:

  1. Incorrect data types in your DynamoDB item structure - DynamoDB requires items to be formatted with explicit type descriptors (e.g., {'S': 'string_value'} for strings, {'N': 'number_value'} for numbers). If your code is sending plain JavaScript objects without proper DynamoDB type formatting, this error will occur.

  2. Malformed JSON or nested structures - The error message "Start of structure or map found where not expected" suggests that the data structure being sent doesn't match DynamoDB's expected format.

  3. Recent code changes - Even if you haven't intentionally modified your Lambda code, check if there were any dependency updates, environment variable changes, or deployment pipeline modifications that could have altered how data is being formatted.

To troubleshoot:

  • Review your Lambda function code, particularly the sections that construct the DynamoDB item before calling putItem or updateItem
  • Verify that all attribute values include proper DynamoDB type descriptors
  • Add logging to capture the exact payload being sent to DynamoDB before the API call
  • Check if you're using the DynamoDB Document Client (which handles type conversion automatically) versus the standard DynamoDB client (which requires explicit type formatting)
  • Compare your current code against a previous working version to identify any differences

For additional assistance with your specific implementation, you can add more details about your code structure to your existing case through the AWS Support Center at https://console.aws.amazon.com/support/.
Sources
Using Lambda functions in AWS SAM and Infrastructure Composer - AWS Lambda

answered 24 days ago

AWS
EXPERT

reviewed 23 days ago

AWS
SUPPORT ENGINEER

reviewed 24 days ago

0
Accepted Answer

This one looks like a client-side serialization problem rather than anything that changed on the DynamoDB side. Two things in the error give it away: the '$fault': 'client' with a 400 status, and the stack trace going through AwsJson1_0Protocol.handleError and the @smithy/core schema/protocol serializer. So the request never really reached DynamoDB in a valid form — the SDK couldn't serialize it and bailed out first. That's also why you didn't get any service notification.

The message Start of structure or map found where not expected basically means the serializer hit an object/map somewhere it expected a different type, most often a list.

Since nothing changed in your own code, I'd start by checking the SDK version. The managed Node.js runtimes ship their own copy of the v3 SDK, and that version gets bumped over time as AWS updates the runtime. The newer serializer is stricter about request shapes, so something that used to go through can now throw SerializationException. I can't say for certain that's what happened here, but comparing the SDK version in your function now vs. before should tell you pretty quickly.

The usual causes for this particular error:

  • Mixing marshalled and unmarshalled input — e.g. sending already-marshalled values like { S: "value" } into DynamoDBDocumentClient, or sending plain objects to the low-level DynamoDBClient without marshall(). Best to stick to one.
  • A field that should be a list being passed as an object (or the reverse).
  • undefined or empty values sneaking into Item, Key, or ExpressionAttributeValues.

A couple of things that tend to help: log the exact params going into the command and diff them against the API reference field by field, and consider bundling @aws-sdk/client-dynamodb and @aws-sdk/lib-dynamodb in your package (or a layer) and pinning them in package.json so the runtime's SDK version isn't controlling behavior for you.

Some references:

AWS

answered 24 days ago

EXPERT

reviewed 23 days ago

0

Hi,

Thank you for your answer it helped us during the investigation. The error was we sent a string for a date instead of the good format. We changed it by adding in our code the toISOString() function for the format date.

Your feedback has put us on the right track.

Regards,

answered 21 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.