fix(mongo): initialise the data directory off the port the server binds - #13593

What

docker compose up -d --wait intermittently fails before any test runs, on a fresh
volume only:

 Container appwrite-mongodb  Error
dependency failed to start: container appwrite-mongodb is unhealthy

Seen on run 34374778610,
job Tests / E2E / PostgreSQL (shared) / Locale. The lane reports a health failure
and skips "Run tests" entirely.

Why

On a fresh /data/db the standard mongo entrypoint creates the users and runs
/docker-entrypoint-initdb.d against a temporary mongod on 127.0.0.1:27017, stops
it with mongod --shutdown, then execs the real server on 0.0.0.0:27017.

That handover is unsynchronised:

• mongod --shutdown returns once the server it signalled clears
  <dbpath>/mongod.lock. Verified directly: point --shutdown at a process that
  ignores SIGTERM and it blocks; delete mongod.lock underneath it and it returns
  immediately, with the process still running. Deleting the --pidfilepath file
  instead changes nothing.
• A mongod releases its listening socket only when the process exits, several
  steps after the lock goes. "Shutdown: Closing listener sockets" is logged while
  127.0.0.1:27017 is still LISTEN in /proc/net/tcp.
• The real server binds ~1ms after it starts (setUpTransportLayer runs before
  WiredTiger), so there is no slack to absorb a slow shutdown tail.

When the tail outlasts the handover:

Error setting up transport layer ... 0.0.0.0:27017 :: caused by ::
setup bind :: caused by :: Address already in use

mongod exits 48, the container goes with it, and every service that depends_on
mongodb fails under --wait. In the CI dump the temporary server had reached
"Dropping the scope cache for shutdown" and had still not logged "Now exiting"
when the real one tried to bind 1.08s later.

Two things it is not: --bind_ip_all is not carried into the init phase (the
standard entrypoint strips it and pins --bind_ip 127.0.0.1 --port 27017, and the CI
log confirms "bindIp":"127.0.0.1"); and lingering TIME_WAIT/FIN_WAIT2 sockets on
127.0.0.1:27017 do not block the wildcard bind, which I checked by holding
connections open across a shutdown and binding over them successfully.

How

Initialise the data directory in mongo-entrypoint.sh, on 27018, and wait on the
process (wait "$INIT_SERVER") rather than on its lock file. The standard
entrypoint then finds an initialised directory, starts no second server, and execs
straight through, so mongod is PID 1 on every boot including the first.

mongo-init.js moves out of /docker-entrypoint-initdb.d, because anything left in
there sends the standard entrypoint back to the temporary server regardless of the
data directory. mongo-init-replicaset.sh goes too: unreferenced since the
healthcheck took over replica set initiation, and written to be mounted into that
same directory.

Users are unchanged, byte for byte against the current entrypoint:
root@admin with the root role, and _APP_DB_USER@admin with readWrite on
_APP_DB_SCHEMA.

Verification

Forced the race by freezing the temporary server the instant it clears
mongod.lock, which is what a loaded runner does to its shutdown tail:

tests/unit/Docker/Compose/GeneratorTest.php 11/11. The new
testRewritesMongoBindMountsToHostPathOnPublishedVersions covers a real gap: the
existing rewrite test passes version => 'local', which short-circuits the
HOST_PATH_REWRITABLE_BINDS check, so nothing exercised the constant this PR edits.
Seen red against the pre-change Generator.php and green after.

composer lint (Pint, PSR-12) clean on both PHP files, prettier --check clean on
the compose files, shellcheck clean on mongo-entrypoint.sh.

Not changed

The healthcheck still doubles as the replica set initializer. Reviewed while here,
left alone as out of scope for this failure, worth a follow-up:

• rs.initiate runs from the health probe, so the set is not initiated until the
  first probe one full interval after start, and mongodb needs two probes (~20s) to
  report healthy on every fresh stack.
• 2>/dev/null plus two swallowed catch (e) {} make a wrong password or a rejected
  initiate indistinguishable from "not ready yet". .State.Health.Log is always
  empty, which is the opposite of what you want when diagnosing this class of CI
  failure.

Supersedes #13591, which takes the failure as given and restarts mongod after it, and
whose commit message attributes the collision to the real server spending "about a
second opening WiredTiger before it binds" (it binds first, ~1ms in).

🤖 Generated with Claude Code