AWS DynamoDB error: ValidationException: One or more parameter values were invalid: Condition parameter type does not match schema type

Executing a query against a Global Secondary Index I got this error:

ValidationException: One or more parameter values were invalid: Condition parameter type does not match schema type

Using the NodeJS Document api, my query looked like this:

let params = {
        "TableName": "exampletable",
        "IndexName": "example-createdate-index",
        "KeyConditionExpression": "exampleattr1 = :exampleattr1",
        "ExpressionAttributeValues": {
            ":exampleattr1": { "S": "0" }
        },
        "ProjectionExpression": "createdate, exampletext",
        "ScanIndexForward": false
    }
return docClient.query(params).promise();

The error is saying that one of my query parameter types does not match the values in the schema. I know this value is a String so this looks correct. Following recommendations on this question, it’s suggested to not pass the param type as “S” and let the Document api work out the type itself.Remove the “S” and just passed the value and now it’s working as expected.

Planning to migrate my AWS Lambda Twitter bots to Mastodon

Like everyone else right now, I’m mulling options to migrate away from Twitter, likely to Mastodon (follow me at @kevinhooke@mastodon.social !). Moving my personal usage is relatively simple, other than rebuilding a list of people and tags that I like to follow. I also have a number of Twitter bots running on AWS Lambdas that I’ve built over the years that I should move at some point.

The easy part is that the code that’s running as an AWS Lambda doesn’t need to physically move anywhere, that can continue to run where it is. The part that needs to change is the APIs it’s using to integrate with Twitter and update them to use APIs to post to Mastodon instead.

I’m still in early stage of looking at options so far. I’ve discovered there’s a Mastodon instance, BotsInSpace, that’s specifically for running bots, so that addresses that first step, where they need to run against. I’ve also been reading through a few articles on developing bots for Mastodon such as this one. So far looks like it shouldn’t be too much of a big deal to move them across.

‘serverless invoke local’ with Java Lambdas

If you create a Java Lambda with the provided template, you’re probably returning a response using the provided ApiGatewayResponseClass. If you run your Lambda locally with ‘serverless invoke local –function functioname’, you’ll see a response like this:

Serverless: Invoke invoke:local
Serverless: In order to get human-readable output, please implement "toString()" method of your "ApiGatewayResponse" object.

com.serverless.ApiGatewayResponse@3bd3d05e

Any other logger output will appear in your console, but in order to see the actual content of your ApiGatewayResponse, add a toString() method as the message suggests.

You include any of the properties in ApiGatewayResponse, but if you’re just interested in the JSON payload in the body of the response, then just adding this will return the body:

public String toString(){
    return this.body;
}