fix(compose): probe postgres over TCP so dependents aren't released early (#106)

postgres' docker-entrypoint runs a temporary server reachable only over the
Unix socket (listen_addresses='') once initdb has finished, so it can create
the database and run docker-entrypoint-initdb.d. A pg_isready probe without
-h talks to that socket, so it answers "accepting connections" while no TCP
listener exists at all. compose then marks the service healthy and
depends_on: service_healthy releases the dependent straight into
ECONNREFUSED.

Measured at ~235ms with no initdb.d scripts, and at 1.2s of false-healthy
followed by a 2.7s shutdown checkpoint in the CI failure this was diagnosed
from. Reproduced on postgres 13.3, 15 and 16. Only bites on a fresh volume,
since a populated one skips the temporary server entirely -- which is why it
surfaced as a rare flake rather than a consistent failure.

Passing -h 127.0.0.1 forces a TCP probe, which tracks the real listener in
every phase: the stock images ship listen_addresses = '*', and during startup
or recovery pg_isready reports "rejecting connections", so the probe
correctly keeps failing until the server can actually serve.

Signed-off-by: slayerjain <shubhamkjain@outlook.com>

Author: slayerjain

doccano-django/docker-compose.yml

@@ -57,7 +57,21 @@ services:
       POSTGRES_PASSWORD: doccano
       POSTGRES_DB: doccano
     healthcheck:
-      test: ["CMD-SHELL", "pg_isready -U doccano -d doccano"]
+      # -h 127.0.0.1 is load-bearing: it forces a TCP probe.
+      #
+      # Without it pg_isready talks to the Unix socket, and postgres'
+      # docker-entrypoint runs a *temporary* server reachable only over that
+      # socket (listen_addresses='') once initdb has finished, to create the
+      # database and run docker-entrypoint-initdb.d. The socket therefore
+      # answers "accepting connections" while no TCP listener exists at all,
+      # so compose marks this service healthy and depends_on:
+      # service_healthy releases the dependent straight into ECONNREFUSED.
+      #
+      # Short but real: ~235ms with no initdb.d scripts, and 1.2s of
+      # false-healthy plus a 2.7s shutdown checkpoint in the CI failure this
+      # was diagnosed from. Only bites on a fresh volume -- a populated one
+      # skips the temporary server entirely, which is why it failed rarely.
+      test: ["CMD-SHELL", "pg_isready -h 127.0.0.1 -U doccano -d doccano"]
       interval: 5s
       timeout: 5s
       retries: 20