fix: make PostgreSQL data plane reachable on a shared Docker network (+ compat test)#97
Merged
hectorvent merged 3 commits intoJul 1, 2026
Conversation
Add PostgresCompatibilityTest to sdk-test-java, mirroring SqlCompatibilityTest: create a flexible server via ARM, fetch the connection string from /connect, then connect over JDBC (org.postgresql) and exercise the real data plane — CREATE DATABASE, CREATE TABLE, batch INSERT, SELECT, UPDATE, DROP — plus checkNameAvailability, firewall-rule CRUD, configuration round-trip, database delete, and admin-reset. Gated on a reachable emulator (skips otherwise), so it runs in the native compatibility matrix where Docker is available. This closes the data-plane coverage gap for the PostgreSQL service: the existing tests cover the control plane and mocked mode, but nothing verified an app can actually connect to the postgres container end to end.
When floci-az runs inside a container (docker-compose / CI), the postgres sidecar is reachable by other containers via its name on the shared Docker network, not via localhost:<published-port>. The connection info hardcoded localhost, so apps in a networked deployment could not connect to the database — and the readiness probe silently timed out against an unreachable localhost. This surfaced as the new PostgresCompatibilityTest failing in the native compatibility matrix with "Connection to localhost:5432 refused". Mirror RedisCacheManager: attach the container to the configured Docker network and, when running inside a container (ContainerDetector), report the container name + the container port as the reachable endpoint; otherwise localhost + the published port. The /connect response, fullyQualifiedDomainName, and the readiness probe now all use the reachable host. ServerEntry gains a (non-persisted) host field.
Assert the derived app-database URL differs from the default-database URL, so a future change to the connection-string format surfaces as a clear failure instead of the DDL/DML test silently running against the default `postgres` database. Also document that the `localPort` convenience field reflects the reachable port and that /connect is the authoritative source for host + port.
hectorvent
approved these changes
Jul 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds the first data-plane compatibility test for the PostgreSQL Flexible Server service
(#80) — and fixes the real bug it surfaced.
PostgresCompatibilityTest(insdk-test-java) creates a flexible server via ARM, fetches theconnection string from
/connect, then connects over JDBC (org.postgresql) and exercises thelive data plane:
CREATE DATABASE,CREATE TABLE, batchINSERT,SELECT,UPDATE,DROP,plus
checkNameAvailability, firewall-rule CRUD, configuration round-trip, and admin-reset.The bug it caught
Running in the native compat matrix, the JDBC steps failed with
Connection to localhost:5432 refused. Root cause: when floci-az runs inside a container(docker-compose / CI), the postgres sidecar is reachable by other containers via its name on
the shared Docker network, not
localhost:<published-port>. The PostgreSQL service hardcodedlocalhost, so applications in any networked deployment could not reach the database, and thereadiness probe silently timed out against an unreachable
localhost. (Azure SQL has the samelimitation, but its compat test is EULA-skipped so it never ran.)
The fix
Mirror
RedisCacheManager: attach the container to the configured Docker network, and useContainerDetectorto report the container name + container port as the reachable endpointwhen running in a container (otherwise
localhost+ the published port)./connect,fullyQualifiedDomainName, and the readiness probe all now use the reachable host.ServerEntrygains a non-persistedhostfield.Tests
PostgresCompatibilityTest(gated on a reachable emulator; runs in the native matrix).hostfield; full suite green (235).Net effect: container-backed PostgreSQL now works in docker-compose/CI deployments, not just
with host networking — verified end-to-end by the new test.