Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Prod database is coupled to the Elastic Beanstalk environment with DBDeletionPolicy: Delete

Open
  • Is something wrong?
#405 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
18/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
ansible, aws, postgresql
Domain
databases, devops, infrastructure

Research direction

The work sits in the production AWS setup, not the repo's code: the EB environment robocode-prod and its coupled RDS instance, whose DBDeletionPolicy is Delete. First step is to verify backup retention and take a manual snapshot in the console, which the issue asks for. Done means the policy is changed to Retain or the DB is decoupled, and backups are confirmed; this needs infrastructure access and a planned-downtime plan.

Written by the indexing model from the issue text.

Description

priority: high tech-debt

Found while investigating the robocodejs-rds-freeable-memory alarm on 2026-10-09. Not the cause of that alarm — a separate durability risk noticed en route.

The problem

The production Postgres instance is an EB-coupled RDS instance, created and owned by the robocode-prod environment's CloudFormation stack rather than standing on its own. From describe-configuration-settings --environment-name robocode-prod, namespace aws:rds:dbinstance:

option value
HasCoupledDatabase true
DBDeletionPolicy Delete
DBInstanceClass db.t3.micro
DBAllocatedStorage 5
MultiAZDatabase false
DBEngine postgres

Instance id: awseb-e-mgqxmtm3pq-stack-awsebrdsdatabase-9iougzgztliw.

Terminating or rebuilding robocode-prod destroys the production database. That includes every user account, app source, arena, roster, API token and Elo rating. Rebuild environment in the EB console is a single menu item with no special confirmation about the database, and "recreate the environment" is a routine remedy for a wedged environment — including one we have reached for before (see the deploy-failure notes in CLAUDE.md about Immutable-swap and command-timeout failures).

This is also why the DB is a db.t3.micro with 5 GB: those are EB's coupled-RDS defaults, not a sizing decision. The 1 GB of RAM is what made the memory alarm possible in the first place.

Why it matters beyond the obvious

  • Single-AZ, so no failover.
  • The DB's lifecycle is tied to a compute environment it has no business sharing. Any environment-level operation becomes a data-level risk.
  • Backup retention is unverified. The github-cloudspaces IAM user has no rds:Describe* permission, so describe-db-instances, describe-db-snapshots and describe-events all return AccessDenied from CI/dev tooling. Nobody has confirmed from here whether automated backups are on, what the retention window is, or whether any snapshot exists. If retention is 0, there is currently no recovery path at all.

Suggested work, in order

  1. Verify backups now, in the console — automated backup retention > 0, and take one manual snapshot immediately as a floor. This is the cheap step that caps the downside and should happen regardless of everything below.
  2. Decide on decoupling. The standard path is to snapshot, provision a standalone RDS instance outside the EB stack, point RDS_* env vars at it, and then set DBDeletionPolicy: Retain (or remove the coupled DB). This is a planned-downtime migration, so it wants its own plan.
  3. As an interim mitigation, flip DBDeletionPolicy from Delete to Retain. Much smaller change than a migration and removes the catastrophic case — a rebuild would orphan the instance rather than delete it. Worth confirming whether EB allows changing this on an existing coupled DB without replacement.
  4. Consider sizing while migrating. db.t3.micro (1 GB) was already under memory pressure: FreeableMemory fell ~19 MB/month over 90 days (187 → 130 MB) with swap in steady use. Retention on ranked_match (#401) addresses the growth driver, but the instance is small for the job.
  5. Grant read-only rds:Describe* to the tooling IAM user so DB health is observable from CI/dev rather than only the console.

Related

  • #401 (ladder throttle + ranked_match retention) — addresses what was consuming the DB, not where it lives.
  • CLAUDE.md "Accepted / deferred security risks" and the prod-deploy notes.

Separately noted and not covered here: MaxSize=4 on an app that is not horizontally scalable; the env-level ConfigDocument still shadowing PR #319's 4xx health rules; and the unconfigured pg pool (default max: 10, saturating).

Dominant language
TypeScript
Stars
0
Forks
0
Avg merge
8m
Merged PRs (30d)
8

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from LeeAdcock/robocodeJs.com

All issues in LeeAdcock/robocodeJs.com

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.