[Bug report] PostgreSQL integration tests fail due to incorrect container port mapping

[bharos]

Version

main branch

Describe what's wrong

PostgreSQL integration tests fail to connect to the container because the code uses internal container networking instead of host-mapped ports.

Issue:

• Tests use getContainerIpAddress():5432 which points to internal Docker network (e.g., 172.17.0.2:5432)
• This address is not accessible from the host running the tests
• Docker maps container port 5432 to a random host port, but tests don't use the mapped port

Expected: Tests should connect using host-accessible endpoints Actual: Connection failures and test timeouts

Error message and/or stacktrace

java.sql.SQLException: Connection to 172.17.0.2:5432 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.

OR

[Test hangs indefinitely due to connection timeout]

Logs show: 2025-11-05 ERROR PostgreSQLContainer - Command [pg_isready, -h, localhost, -U, root] exited with 2 2025-11-05 ERROR PostgreSQLContainer - stderr: pg_isready: could not connect to server: Connection refused

How to reproduce

# What Docker actually does:
docker run -p 32768:5432 postgres:13
#               ↑      ↑
#         host port   container port

# Old code tries: 172.17.0.2:5432 
# Should use:     localhost:32768 

Additional context

No response

[mchades]

Did you follow the doc to use mac-docker-connector or orbstack?

[bharos]

Did you follow the doc to use mac-docker-connector or orbstack?

This issue happens because Testcontainers creates separate PostgreSQL container, not embedded in gravitino. So this fix just makes sure if there's a port mapping for Postgres container done by Docker, it takes that into consideration. As you can see in the example

docker run -p 32768:5432 postgres:13
#               ↑      ↑
#         host port   container port

Without fix, it always tries to connect to 5432, but now it should get the mapped port.

Also, this is backward compatible anyways, just handles another case

[mchades]

I got it. So it's an improvement, not a bug.

Tests use getContainerIpAddress():5432 which points to internal Docker network (e.g., 172.17.0.2:5432)

As you mentioned in the issue, the current integration is based on the Docker network. If you're using macOS, you can use Orbstack or mac-docker-connector (see before test in the documentation). On Linux, no additional configuration is needed, as the host can access the Docker network directly.

If I have misunderstood, please correct me.

[bharos]

You're correct - OrbStack or mac-docker-connector.sh probably would have prevented this issue per the documentation. So that way, probably we can call this an improvement.

I think this change makes it more portable and reliable, and uses proper Testcontainers APIs (container.getHost(), getMappedPort()).

[mchades]

I think this change makes it more portable and reliable, and uses proper Testcontainers APIs (container.getHost(), getMappedPort()).

But I am worried that doing so may not cover the existing Trino integration test scenarios: Trino's integration tests will start multiple containers, and multiple containers need to access each other. Will using getMappedPort() lead to the containers being unable to access each other?

[bharos]

Got it, thanks for bringing this up. I am not 100% sure. Probably I can trigger those tests. Do they run as part of the CI

[mchades]

Do they run as part of the CI

yes. Here it is: https://github.com/apache/gravitino/blob/3c7ede78688c2dbb580722735b2a222ec7f1ad57/.github/workflows/trino-integration-test.yml#L85-L89