test(integration): widen the Postgres readiness window, which was the flake

Three red gates in one session, three different tests across two ports, one
signature: "postgres container '...' did not become ready within 30s". Python
query scenarios, Java query scenarios, Python jsonb. Each passed on a re-run with
nothing else going.

It is not a product failure and it never reaches test logic -- it fires while the
container is still booting. But a gate that goes red for a reason indistinguishable
from a real failure is a red issue in its own right: the only way to tell the two
apart is to re-run and see, which is exactly the habit that lets a genuine failure
get waved through as "probably the flake".

The cause is arithmetic rather than mysterious. A FULL local-CI run has several
ports spinning their own Postgres concurrently; 30s is a guess that holds when one
port runs alone and does not when four do. All four ports hardcoded the same 30 --
TS, Java, Kotlin and Python each with their own copy of the same loop and the same
message.

Now 120s in all four, overridable with MO_PG_READY_TIMEOUT_S, and the failure
message reports the window actually used instead of a hardcoded "30s" that could
drift from the constant beside it.

Raising the bound costs nothing in the normal case: every one of these polls at
250ms and returns the instant the container answers, so a fast container is
unaffected. The only thing that changes is how long a genuinely broken container
takes to give up -- and for a CI gate, 90 extra seconds once is cheaper than a
false red that has to be re-run to interpret.

Compiles: java + kotlin integration modules (both sit outside the reactor, so
they are built directly), TS workspace typecheck clean, python parses.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: dmealing

server/java/integration-tests-kotlin/src/test/kotlin/com/metaobjects/integration/kotlin/PostgresContainer.kt

@@ -100,7 +100,12 @@ class PostgresContainer : AutoCloseable {
     }
 
     private fun waitForReady() {
-        val deadline = System.currentTimeMillis() + 30_000
+        // READINESS WINDOW. 30s was too tight: under a FULL local-CI run several ports
+        // spin their own Postgres concurrently, and a container that is merely slow to
+        // boot produces a red gate indistinguishable from a real failure -- it fires
+        // BEFORE any test logic. Raising the bound costs nothing when the container is
+        // ready quickly (this polls every 250ms and returns immediately).
+        val deadline = System.currentTimeMillis() + (READY_TIMEOUT_S * 1000L)
         while (System.currentTimeMillis() < deadline) {
             try {
                 val p = ProcessBuilder("docker", "exec", name, "pg_isready", "-U", PG_USER)
@@ -117,7 +122,7 @@ class PostgresContainer : AutoCloseable {
                 return
             }
         }
-        throw RuntimeException("postgres container '$name' did not become ready within 30s")
+        throw RuntimeException("postgres container '$name' did not become ready within ${READY_TIMEOUT_S}s")
     }
 
     private fun canConnect(): Boolean = try {
@@ -133,6 +138,10 @@ class PostgresContainer : AutoCloseable {
         private const val PG_USER = "postgres"
         private const val PG_PASSWORD = "test"
 
+        /** Container readiness bound, seconds. Overridable so a loaded CI box can widen it. */
+        private val READY_TIMEOUT_S: Int =
+            (System.getenv("MO_PG_READY_TIMEOUT_S") ?: "120").toInt()
+
         private fun pickFreePort(): Int = ServerSocket(0).use { it.localPort }
 
         private fun runDocker(vararg args: String): String {

server/java/integration-tests/src/test/java/com/metaobjects/integration/PostgresContainer.java

@@ -148,8 +148,17 @@ private static String runDocker(String... args) {
      * the first window, so we also verify a real JDBC client connection from
      * the host succeeds before returning. Mirrors the TS port's two-phase wait.
      */
+    // READINESS WINDOW. 30s was too tight: under a FULL local-CI run several ports spin
+    // their own Postgres concurrently, and a container that is merely slow to boot
+    // produces a red gate indistinguishable from a real failure -- it fires BEFORE any
+    // test logic. Raising the bound costs nothing when the container is ready quickly
+    // (this polls every 250ms and returns immediately) and only changes how long the
+    // pathological case takes to give up.
+    private static final int READY_TIMEOUT_S =
+        Integer.parseInt(System.getenv().getOrDefault("MO_PG_READY_TIMEOUT_S", "120"));
+
     private void waitForReady() {
-        long deadline = System.currentTimeMillis() + 30_000;
+        long deadline = System.currentTimeMillis() + (READY_TIMEOUT_S * 1000L);
         while (System.currentTimeMillis() < deadline) {
             try {
                 Process p = new ProcessBuilder("docker", "exec", name, "pg_isready", "-U", PG_USER)
@@ -160,7 +169,7 @@ private void waitForReady() {
                 Thread.currentThread().interrupt(); return;
             }
         }
-        throw new RuntimeException("postgres container '" + name + "' did not become ready within 30s");
+        throw new RuntimeException("postgres container '" + name + "' did not become ready within " + READY_TIMEOUT_S + "s");
     }
 
     private boolean canConnect() {

server/python/tests/integration/postgres_container.py

@@ -138,9 +138,16 @@ def __exit__(self, *exc: object) -> None:
     # finishes; mirrors the TS/Java two-phase wait).
     # -----------------------------------------------------------------------
 
+    # READINESS WINDOW. 30s was too tight: under a FULL local-CI run several ports
+    # spin their own Postgres concurrently, and a container that is merely slow to
+    # boot produces a red gate indistinguishable from a real failure -- it fires
+    # BEFORE any test logic. Raising the bound costs nothing when the container is
+    # ready quickly (the loop polls every 250ms and returns immediately) and only
+    # changes how long the pathological case takes to give up.
     def _wait_ready(self) -> None:
         import pg8000.dbapi  # local import — pg8000 lives in the `integration` extra
-        deadline = time.monotonic() + 30
+        timeout_s = int(os.environ.get("MO_PG_READY_TIMEOUT_S", "120"))
+        deadline = time.monotonic() + timeout_s
         last_err: Exception | None = None
         while time.monotonic() < deadline:
             ready = subprocess.run(
@@ -159,7 +166,7 @@ def _wait_ready(self) -> None:
                     last_err = e
             time.sleep(0.25)
         raise RuntimeError(
-            f"postgres container '{self._name}' did not become ready within 30s; last err: {last_err}"
+            f"postgres container '{self._name}' did not become ready within {timeout_s}s; last err: {last_err}"
         )
 
 

server/typescript/packages/integration-tests/src/postgres-container.ts

@@ -133,14 +133,22 @@ function runDocker(args: string[]): string {
 // Postgres' first-boot entrypoint starts the server twice (initial init, then
 // the real boot). `pg_isready` can return success during the first window, so
 // we additionally verify a real client connection from the host succeeds.
+// READINESS WINDOW. 30s was too tight: under a FULL local-CI run several ports spin
+// their own Postgres concurrently, and a container that is merely slow to boot
+// produces a red gate indistinguishable from a real failure -- it fires BEFORE any
+// test logic. Raising the bound costs nothing when the container is ready quickly
+// (this polls every 250ms and returns immediately) and only changes how long the
+// pathological case takes to give up.
+const PG_READY_TIMEOUT_S = Number(process.env["MO_PG_READY_TIMEOUT_S"] ?? "120");
+
 async function waitForPgReady(name: string, uri: string): Promise<void> {
-  const deadline = Date.now() + 30_000;
+  const deadline = Date.now() + PG_READY_TIMEOUT_S * 1000;
   while (Date.now() < deadline) {
     const r = spawnSync("docker", ["exec", name, "pg_isready", "-U", "postgres"], { encoding: "utf8" });
     if (r.status === 0 && (await canConnect(uri))) return;
     await new Promise((res) => setTimeout(res, 250));
   }
-  throw new Error(`postgres container '${name}' did not become ready within 30s`);
+  throw new Error(`postgres container '${name}' did not become ready within ${PG_READY_TIMEOUT_S}s`);
 }
 
 async function canConnect(uri: string): Promise<boolean> {