Planning Twitter bot to Mastodon migration / updates – what do I have running right now?

The odd thing about personal bot projects is that after you’ve deployed them and they’re up and running, unless apis change and need to be updated, there’s not much needed to keep them running, if anything. Some of my first bots I deployed as AWS Lambdas I’ve had running several times a day for 5 years. In this time AWS Lambda supported runtimes have come and gone out of support, so the Node6 runtime I was originally using has now definitely passed it’s official support.

This is mostly a todo list to help consolidate my todo list of bots that I need to look at as part of my migration from Twitter to Mastodon, but if you search you can find my previous posts that describe how these were built.

@kevinhookebot

Mostly migrated to @kevinhookebot@botsin.space on Mastodon but running on Twitter and Mastodon at the same time. Sends the same generated text to both at the same time, but replying to the bot either on Twitter or Mastodon will interact with just that bot on that account.

My first Twitterbot project, and has now tweeted over 11k times since 2018 when it went live. This comprises multiple Lambdas to provide different features:

  • a trained RNN text generation model generates random text and tweets every ~ 3 hours. One scheduled AWS Lambda generates the text and inserts to a DynamoDB table. Another scheduled Lambda reads the next tweet from the table and tweets using Twitter’s apis.
  • A scheduled Lambda runs every minutes calling a Twitter api to check for replies and tweets at this account. It replies with one of a number of canned replies
  • If you tweet at this bot with ‘go north|south|east|west it replies with a generated response typical of a text based adventure game. The replies are generated with a template and randomly inserted words (it isn’t actually a game)

@productnamebot

Tweets randomly generated product names using lists of key words. Not yet migrated to Mastondon. Has tweeted 7k times since 2018

@blackjackcard

A BlackJack cardgame bot. Not migrated to Mastodon yet. @ the bot with ‘deal’ to start a game. Tracks game state per player in DynamoDB. Uses Twitter apis to check for replies to the game bot every 5 minutes.

Using VS Code extensions to help with AWS CloudFormation templates

Writing CloudFormation templates by hand is time consuming and error prone. Usually I know what is is that I’m trying to create and and know roughly what the options are, but remembering the exact syntax in json or YAML is near impossible.

VS Code has a number of extensions that can make this a lot easier. Tab code complete with plugins like “CloudFormation Snippets’ makes writing new templates incredibly quick and easy:

By default with this extension, type cfn then Tab to auto complete the skeleton of a CloudFormation template. If you have autocomplete on tab turned off you can turn it on in your VS Code settings, or manually use Ctrl-Space to trigger:

After pressing Tab you get an empty template:

As I’m writing a template for a new DynamoDB table, I enter dynamodb-table under Resources and Tab and it adds the skeleton ready to complete:

This saves time in having to look at what the required and optional attributes are, but unless I’m missing a feature it doesn’t have any auto completion to help select values for some attributes where valid values are from a list of options. For example, for DynamoDB BillingMode, the available options are PROVISIONED or PAY_PER_REQUEST. I can go look that up in the docs here, but it would be nice if it would offer tab complete for those too.

Read AWS IAM permission errors carefully – they tell you everything you need to know (Twitter to Mastodon bot migration)

Migrating my @kevinhookebot Twitter bot to Mastodon, I made some updates to how the Lambda queries a source DynamoDB table for new messages to be posted and ran into this error:

"errorType": "AccessDeniedException",
    "errorMessage": "User: arn:aws:sts::account-id:assumed-role/lambda-kevinhookebot-role/kevinhooketwitterbot-v2-dev-sendTweet is not authorized to perform: dynamodb:Query on resource: arn:aws:dynamodb:us-west-1:account-id:table/tweetbottweets/index/tweetdate-createdate-index because no identity-based policy allows the dynamodb:Query action"

The IAM role I’m reusing does have dynamodb:Query, but only on these resources:

"Resource": [
  "arn:aws:dynamodb:us-west-1:account-id:table/tweetbottweets",
  "arn:aws:dynamodb:us-west-1:account-id:table/tweetbottweets/index/Index",
  "arn:aws:dynamodb:us-west-1:account-id:table/tweetbotreplies"
]

This only includes the table itself, the primary index called Index, and another table tweebotreplies.

Notice this part of the message:

is not authorized to perform: dynamodb:Query on resource: arn:aws:dynamodb:us-west-1:account-id:table/tweetbottweets/index/tweetdate-createdate-index

The issue is this role does not include Query on a new index I added, called tweetdate-createdate-index. To resolve this, add this index to the list of Resources, and problem resolved.