Repository navigation
Closed
Labels
effort/lWeeksWeeksimpact/fewLimited audienceLimited audiencepriority/p2Backlog-worthyBacklog-worthyseverity/highSignificant harmSignificant harmstatus/needs-infoAwaiting clarification from the askerAwaiting clarification from the askertriagedItem has been triagedItem has been triagedtype/bugDefectDefecturgency/this-quarterWithin the quarterWithin the quarter
Description
What happens
The CloudFormation install stack (cloudformation/stacks/CUDly/template.yaml) cannot run the current server.
- The stack still creates six DynamoDB tables (
AWS::DynamoDB::Tableat lines 342, 365, 391, 414, 458 and 477 on main at 6b586cc). It passesCONFIG_TABLE,PLANS_TABLE,HISTORY_TABLE,USERS_TABLE,GROUPS_TABLEandSESSIONS_TABLEto the Lambda (lines 754-759). - It sets no
DB_HOSTor otherDB_*variables, and it creates no Postgres database, credentials secret or VPC access. - The server only supports Postgres.
initConfigStore(internal/server/app.go:1031-1034) returnsdatabase 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 fromdocs/DEPLOYMENT.mdand from the parity scripts and tests that read it (for exampleinternal/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.
Filed by IAmJSD's agent at IAmJSD's request (acting owner while the maintainers are away).
Metadata
Metadata
Assignees
Labels
effort/lWeeksWeeksimpact/fewLimited audienceLimited audiencepriority/p2Backlog-worthyBacklog-worthyseverity/highSignificant harmSignificant harmstatus/needs-infoAwaiting clarification from the askerAwaiting clarification from the askertriagedItem has been triagedItem has been triagedtype/bugDefectDefecturgency/this-quarterWithin the quarterWithin the quarter
Activity
IAmJSD commentedon Oct 28, 2026
Acting-owner decision (D29, IAmJSD, 2026-10-28): retire the CloudFormation install stack (cloudformation/stacks/CUDly) and point users to the Terraform installs. The federation CloudFormation templates are unaffected. A PR is in progress.
revert(cfn): leave the CloudFormation install stack to its retirement
test(iac): give the schedule-default test its own default regex
fix(cfn): retire the CloudFormation install stack (LeanerCloud#1577)
fix(iac): fire delayed purchases by default; collect AWS recommendati…