You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(cfn): CloudFormation CUDly stack can't start the current server (no DB_HOST; still provisions DynamoDB) #1432
The CloudFormation install stack (cloudformation/stacks/CUDly/template.yaml) cannot run the current server.
The stack still creates six DynamoDB tables (AWS::DynamoDB::Table at lines 342, 365, 391, 414, 458 and 477 on main at 6b586cc). It passes CONFIG_TABLE, PLANS_TABLE, HISTORY_TABLE, USERS_TABLE, GROUPS_TABLE and SESSIONS_TABLE to the Lambda (lines 754-759).
It sets no DB_HOST or other DB_* variables, and it creates no Postgres database, credentials secret or VPC access.
The server only supports Postgres. initConfigStore (internal/server/app.go:1031-1034) returns database configuration required: DB_HOST must be set, so startup fails. Every request and every scheduled task on this stack fails.
This comes from reading the code; the stack was not deployed. #1300 (merged) added the EventBridge schedules to this template; its body flagged this bug as out of scope. docs/DEPLOYMENT.md still lists the stack as a deployment option.
Impact
Anyone who installs through CloudFormation gets a stack that deploys but cannot serve anything. The Terraform install paths are not affected.
Owner decision needed
The fix depends on a product choice that is for the owners to make:
Move the stack to Postgres. This is a large job: VPC and subnets, RDS (or Aurora), the credentials secret and its rotation, Lambda VPC access and connection limits, migrations, and IAM parity with the Terraform AWS install.
Retire the stack. Delete cloudformation/stacks/CUDly, remove it from docs/DEPLOYMENT.md and from the parity scripts and tests that read it (for example internal/testutil/lambdatimeout), and point users to the Terraform install. Smaller, but it removes an advertised install path (one that does not work today).
Acceptance criteria
The owners record which option they choose on this issue.
Option 1: a fresh stack starts the server against Postgres, and its CFN lint and template tests pass.
Option 2: the template and every reference to it are removed or redirected, and the docs no longer offer CloudFormation as an install path.
Activity