A ConfigError raised for a non-root database section now names that section in Field (ADR-076) while its Action still names the root environment variable. The two halves of the same error point at different databases:
config_invalid: databases.reporting.port required set DATABASE_PORT env var or add database.port to config.yaml
^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^ ^^^^^^^^^^^^^
the section that failed configures a DIFFERENT section
config.Load maps env keys by lowercasing and replacing _ with ., so the variable that actually configures that section is DATABASES_REPORTING_PORT. An operator who follows the Action edits the primary database and the original failure persists.
The same applies to a static tenant: the fix for multitenant.tenants.acme.database.port is MULTITENANT_TENANTS_ACME_DATABASE_PORT, not DATABASE_PORT.
History
The hint was always root-spelled — this is not new — but until ADR-076 the whole error was wrapped in a databases.reporting: prefix, which framed the root-spelled hint as a template for the named section. With the path moved into Field the wrapper is gone (it would print the path twice), so the inconsistency is now visible inside one error rather than softened by framing. #1025's brief scoped hint-rewriting out explicitly; ADR-076 records the deferral and its cost.
Suggested shape
dbSection already knows the path and already rewrites Field; the same head-swap applied to the YAML path in Action, plus keyToEnvVar on the qualified key for the variable name, produces a correct hint with no new plumbing. Two open questions worth answering first:
- Should
Action be rewritten, or blanked for non-root placements? A wrong hint is worse than none, but none is worse than a right one.
- Is
Action load-bearing for anyone programmatically, or is it purely operator-facing text? If the latter, this is a free fix.
The deeper alternative in ADR-076 — giving normalizeDatabaseValues the section so its errors are born addressed — would fix Action at the point of construction and is the better home if that refactor happens (#1113).
A
ConfigErrorraised for a non-root database section now names that section inField(ADR-076) while itsActionstill names the root environment variable. The two halves of the same error point at different databases:config.Loadmaps env keys by lowercasing and replacing_with., so the variable that actually configures that section isDATABASES_REPORTING_PORT. An operator who follows theActionedits the primary database and the original failure persists.The same applies to a static tenant: the fix for
multitenant.tenants.acme.database.portisMULTITENANT_TENANTS_ACME_DATABASE_PORT, notDATABASE_PORT.History
The hint was always root-spelled — this is not new — but until ADR-076 the whole error was wrapped in a
databases.reporting:prefix, which framed the root-spelled hint as a template for the named section. With the path moved intoFieldthe wrapper is gone (it would print the path twice), so the inconsistency is now visible inside one error rather than softened by framing. #1025's brief scoped hint-rewriting out explicitly; ADR-076 records the deferral and its cost.Suggested shape
dbSectionalready knows the path and already rewritesField; the same head-swap applied to the YAML path inAction, pluskeyToEnvVaron the qualified key for the variable name, produces a correct hint with no new plumbing. Two open questions worth answering first:Actionbe rewritten, or blanked for non-root placements? A wrong hint is worse than none, but none is worse than a right one.Actionload-bearing for anyone programmatically, or is it purely operator-facing text? If the latter, this is a free fix.The deeper alternative in ADR-076 — giving
normalizeDatabaseValuesthe section so its errors are born addressed — would fixActionat the point of construction and is the better home if that refactor happens (#1113).