Deployment-readiness gap (#244), BLOCKER.
Problem
Many managed-Postgres platforms expose the connection as a libpq-style
postgresql://user:pass@host:5432/db URI. Npgsql's connection-string parser
accepts only key-value form (Host=…;Username=…;Password=…;Database=…) — a
postgresql:// URI throws at data-source construction. The value flows unmodified:
GetConnectionString("Default") (Program.cs:192) → builder.UseNpgsql(connectionString) (PostgresDbContextConfigurator.cs). A repo-wide search confirms there is no URI→key-value conversion anywhere. On any host that hands us a URI, the process throws at startup before it binds a port.
This is a portable robustness fix, not tied to one provider — URI-form connection strings are the norm across managed-Postgres platforms.
Fix (app-side)
Add a small postgresql:// → NpgsqlConnectionStringBuilder shim in
PostgresDbContextConfigurator (use System.Uri + the builder, not string
hacking — prefer framework facilities): if the configured connection string
parses as a postgres/postgresql URI, translate host / port / user / password /
database (and query params such as sslmode) into key-value form before
UseNpgsql; otherwise pass it through unchanged. Which platform env-var holds the
URI is deploy-repo config, not app code.
Verify
Set ConnectionStrings__Default=postgresql://u:p@h:5432/db and boot — reproduces
the throw today; after the fix, parses and connects. Key-value strings keep working
unchanged.
Part of the #244 deployment-readiness audit; tracked in epic #15.
Deployment-readiness gap (#244), BLOCKER.
Problem
Many managed-Postgres platforms expose the connection as a libpq-style
postgresql://user:pass@host:5432/dbURI. Npgsql's connection-string parseraccepts only key-value form (
Host=…;Username=…;Password=…;Database=…) — apostgresql://URI throws at data-source construction. The value flows unmodified:GetConnectionString("Default")(Program.cs:192) →builder.UseNpgsql(connectionString)(PostgresDbContextConfigurator.cs). A repo-wide search confirms there is no URI→key-value conversion anywhere. On any host that hands us a URI, the process throws at startup before it binds a port.This is a portable robustness fix, not tied to one provider — URI-form connection strings are the norm across managed-Postgres platforms.
Fix (app-side)
Add a small
postgresql://→NpgsqlConnectionStringBuildershim inPostgresDbContextConfigurator(useSystem.Uri+ the builder, not stringhacking — prefer framework facilities): if the configured connection string
parses as a
postgres/postgresqlURI, translate host / port / user / password /database (and query params such as
sslmode) into key-value form beforeUseNpgsql; otherwise pass it through unchanged. Which platform env-var holds theURI is deploy-repo config, not app code.
Verify
Set
ConnectionStrings__Default=postgresql://u:p@h:5432/dband boot — reproducesthe throw today; after the fix, parses and connects. Key-value strings keep working
unchanged.
Part of the #244 deployment-readiness audit; tracked in epic #15.