[thomasluizon]

Change

infra/configuration.tf now takes each database name from its Render Postgres internal connection URL when constructing both API connection strings. The username follows the corresponding resource's database_user. infra/README.md documents setting api_database = "render" during the production cutover and removing duplicated service variables after the linked group is verified.

Closes thomasluizon/orbit-tickets#819.

Test evidence

• terraform fmt -check -recursive infra passed.
• terraform -chdir=infra validate passed.
• node tools/check-dashes.mjs --files infra/configuration.tf infra/README.md and node tools/check-timeless.mjs --staged passed.
• dotnet build Orbit.slnx passed with zero errors. dotnet test passed all 6,813 tests.
• A state-backed terraform -chdir=infra console check with api_database=render and both required web digest variables set to valid placeholder digests evaluated the connection string locals. The expression was { production = { for key, value in local.production_api_database_values : key => nonsensitive(regex("Database=([^;]+)", value)[0]) }, staging = { for key in local.database_keys : key => nonsensitive(regex("Database=([^;]+)", local.staging_render_npgsql)[0]) } }. Passwords were not printed. Result:

production ConnectionStrings__DefaultConnection = orbit_production_9g8l
production ConnectionStrings__SessionConnection = orbit_production_9g8l
staging ConnectionStrings__DefaultConnection = orbit_staging_jo8c
staging ConnectionStrings__SessionConnection = orbit_staging_jo8c

• A live terraform plan -refresh=false with api_database=render could not complete because RENDER_API_KEY is unset in this shell. Terraform reported Error: Missing Render API Key. The plan therefore did not establish the web service change set.
• No existing Terraform regression test covers this expression, so an unchanged test result and a failing strengthened test before the fix were unavailable. The state-backed console check verifies the changed expression against the saved Render resource values.
• dotnet build Orbit.slnx: 0 errors.
• dotnet test Orbit.slnx --no-build: 6,842 passed, 0 failed.
• Terraform format and validation passed in both roots; 9 infrastructure tests passed.
• Saved-state plans with -refresh=false showed no Postgres replacement or web-service update. The planned connection strings named orbit_production_9g8l and orbit_staging_jo8c, with passwords excluded from the output.
• Orchestrator, refreshed read-only plans with live Render, Cloudflare and AWS credentials and the operator allow lists in the ignored local variable files: the main root plans no change to either render_postgres (no replacement, no allow list removal) and no web service update; the staging-database root plans only render_env_group.staging_database and its link (2 to add, 0 to change, 0 to destroy), keeps the allow list, and its connection string names Database=orbit_staging_jo8c (password redacted). The live GET /v1/postgres values are orbit_production_9g8l/orbit_production and orbit_staging_jo8c/orbit_staging. No existing database-name regression test supplied a pre-fix observation; the pre-fix plan of the staging root read database_name = "orbit_staging_jo8c" -> "orbit_staging" # forces replacement.

External interface evidence

The installed Render provider v1.9.1 schema reports render_postgres.connection_info.internal_connection_string as a computed sensitive string and render_postgres.database_user as a string. terraform state pull, filtered to the two Render Postgres resources, showed internal_connection_string and password in each connection_info object. Parsing only the database path from those saved URLs produced orbit_production_9g8l and orbit_staging_jo8c. This can be repeated without exposing credentials using:

terraform -chdir=infra state pull | jq -c '.resources[] | select(.type == "render_postgres") | {resource: .name, database_from_internal_url: (.instances[0].attributes.connection_info.internal_connection_string | capture("^[^:]+://[^/]+/(?<database>[^/?]+)").database)}'

Assumptions

• The production switch belongs in the documented cutover setting in infra/local.tfvars; I did not change the api_database default because the Render group must be verified before production uses it.
• I used Terraform ignore_changes for database_name and database_user so their configured creation values remain usable when staging is replaced. I rejected hard-coding the current suffixed names as creation inputs.
• Operator IP lists belong in ignored local variables and the staging reseed Actions variable. I rejected committing a real address.

Manual steps

• In Render Dashboard, open the orbit-staging Postgres connection screen. Before the staging API switches to the linked environment group, use that instance's connection details to dump database orbit_staging with pg_dump -Fc and restore it into orbit_staging_jo8c with pg_restore --clean --if-exists. Compare table counts in the PostgreSQL console, verify the staging API reads the restored data, then drop orbit_staging. A final database list should contain orbit_staging_jo8c and no orbit_staging.
• In infra/local.tfvars, set the exact key api_database = "render" after confirming production data in the Render Dashboard orbit-production Postgres connection screen. With RENDER_API_KEY and the other documented credentials available, inspect a fresh plan: both production connection keys must name orbit_production_9g8l, and neither web service nor the imported API service may update in place. Apply that approved plan and verify the production API uses the linked orbit-production-api environment group.
• In Render Dashboard, open service orbit-api > Environment. After verifying the linked group, remove direct service values that duplicate orbit-production-api, including ConnectionStrings__DefaultConnection and ConnectionStrings__SessionConnection, and leave ORBIT_TERRAFORM_ENV_GROUP. The service must remain healthy and use orbit_production_9g8l after those direct values are removed.
• Copy orbit_staging into orbit_staging_jo8c using credentials from the staging database’s Render Connections screen before applying the staging environment-group change. Compare records, verify staging API reads from the new database, then drop orbit_staging.
• Set production_postgres_ip_allow_list in infra/local.tfvars and staging_postgres_ip_allow_list in infra/staging-database/local.tfvars from each database’s Render Networking screen. Confirm the plans retain those exact entries.
• Set STAGING_POSTGRES_IP_ALLOW_LIST in the API repository’s GitHub Settings > Secrets and variables > Actions > Variables to the staging list as JSON. Confirm a reseed plan retains it.
• Apply the staging root, then the main root after the data copy and plan checks. For the later production cutover, set api_database = "render" in infra/local.tfvars, apply its reviewed plan, and verify the production API connection. Then remove duplicated direct connection variables on the Render production API Environment screen; confirm the linked group still supplies both connections.

[pullfrog]

Important

The staging connection switch needs a documented data migration prerequisite before the first apply.

Reviewed changes The Render database connection strings and cutover instructions were reviewed against the Terraform resources and staging startup settings.

• Database names: Both API connection strings now use the suffixed database names from the corresponding Render internal URLs and the resource database users.
• Cutover sequence: The runbook separates initial production environment-group linkage from a later production database switch and direct-variable cleanup.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using GPT Sol ｜ 𝕏}

[pullfrog]

Important

The staging database name change makes the reseed workflow reject its own replacement database before migration or seeding.

Reviewed changes Reviewed the new Terraform and runbook changes since the prior Pullfrog review.

• Staging cutover: Added a prerequisite to copy and verify staging data before linking the new database environment group.
• Database lifecycle: Moved staging connection construction into the staging Terraform root, used the Render URL database name, and preserved operator IP allow lists across both roots and reseeds.
• Production cutover: Kept the production database switch behind api_database = "render" and documented checks before removing direct service variables.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using GPT Sol ｜ 𝕏}

[pullfrog]

✅ No new issues found.

Reviewed changes Reviewed the staging seed target fix and merged base changes since the prior Pullfrog review.

• Seed target validation: Accepted the Render-suffixed staging database name while retaining the staging host and user checks, with tests for permitted and rejected targets.

  ^{｜ View workflow run ｜ Using GPT Sol ｜ 𝕏}

[pullfrog]

✅ No new issues found.

Reviewed changes Reviewed the staging seed database-name matcher change since the prior Pullfrog review.

• Bounded matcher: Replaced the dynamic regex with an equivalent source-generated matcher with a one-second timeout; the staging host and user checks remain unchanged.

  ^{｜ View workflow run ｜ Using GPT Sol ｜ 𝕏}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud