- Newest
- Most votes
- Most comments
The error you're encountering - "Type mismatch for key pk expected: S actual: M" - indicates that DynamoDB is receiving your partition key as a map (M) type instead of a string (S) type, despite your code showing it as a string.
This issue is likely related to how you're using the DynamoDBDocumentClient. When using this client, there are two different approaches to formatting your data:
- Using native JavaScript types (recommended with DocumentClient)
- Using DynamoDB's attribute value format (used with the low-level client)
It appears your code might be mixing these approaches, which can cause inconsistent behavior. The DocumentClient is designed to accept native JSON data, but your error suggests the client might be receiving or interpreting the data in the wrong format.
For the DocumentClient, your request should look like:
{
TableName: "ranking",
Item: {
pk: "20250630_overall-rank", // Plain string, not wrapped in {S: "..."}
sk: "p1967",
expirationSec: ...,
data: ...
}
}
The intermittent nature of the failures (especially under load) suggests there might be an issue with how your data is being prepared or serialized before being sent to DynamoDB, possibly in a concurrent context.
To resolve this:
- Ensure you're consistently using the DocumentClient's expected format (native JS types)
- Check if any part of your code is manually formatting the data as DynamoDB attribute values
- Verify that your concurrent processing isn't somehow altering the data structure
- Consider adding explicit type checking before sending requests
If you're using any middleware or serialization libraries, they might be affecting how your data is formatted before reaching DynamoDB.
Sources
AWS DynamoDB update item command gets ValidationException: The provided key element does not match the schema | AWS re:Post
You mentioned that your function was running for years with no issues. I wonder if the issue might be related to the version of aws-sdk. Are you using the provided package as part of the execution environment or you are including yours?
Relying on the AWS SDK provided by Lambda's execution environment adds risk because AWS can update the SDK version without notice, potentially breaking your application with new versions that introduce breaking changes, modified APIs, or different error handling patterns. The best practice is to include the specific AWS SDK version as a dependency in your deployment package, giving you full control over when to upgrade and ensuring your code behaves predictably across all deployments. While this increases your bundle size, the trade-off is worth it to avoid unexpected runtime failures and maintain application stability.
Relevant content
- asked 4 years ago
- AWS OFFICIALUpdated 3 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago

Bundling the aws-sdk seems to have fixed the issue. Thank you for the suggestions.