fix(mongo): survive losing the first-boot bind race to the init server - #13591

Confidence Score: 5/5

The PR appears safe to merge, with the previously identified shutdown and initialization-failure handling defects resolved.

Summary

• Retries only after MongoDB reports its network initialization exit status.
• Propagates other initialization failures without retrying.
• Forwards termination signals, waits for child shutdown, and avoids restarting after an explicit stop.
• Retains direct exec behavior for initialized data directories.

_{Reviews (2) · Last reviewed commit: "fix(mongo): stop on a signal and raise a..."}

✨ Benchmark results

Comparing main (before) → fix/mongo-first-boot-bind-race-main (after).

⚠️ Before benchmark did not complete — change column unavailable.

Both P1s were valid and are fixed in 87449f3d06. Recording it here because the push moved the anchored lines, so both threads auto-resolved as outdated rather than being answered.

Shutdown Restarts MongoDB. Correct, and worse than a lingering container: the script started the server the caller had just asked to go away. The trap now records which signal arrived, forwards it, and — because a trapped signal makes wait return 128+signal without reaping — waits again until the child is actually gone, so mongod finishes its own shutdown before PID 1 leaves and takes the container with it. It then exits 128+signal instead of starting anything.

Measured on mongo:8.2.5, docker stop both mid-initialisation and once the server was already serving:

All Failures Trigger Retry. Also correct, and the more dangerous of the two. An initialisation script failing after the storage files existed left the second pass looking at a populated /data/db, so it skipped /docker-entrypoint-initdb.d entirely and served a database with no application user, with the original failure unreported. Measured: container running and reachable with the user absent, versus exit 1 and no server now.

The retry is now gated on 48 only — mongod's EXIT_NET_ERROR, what it exits with when it cannot bind. The status arrives unchanged because the standard entrypoint ends in exec "$@", and a temporary server that loses the bind fails inside mongod --fork, whose parent reports 1 — so only the real server can reach 48. Every other status is raised.

On the one red check: Tests / E2E / Antivirus (dedicated) is not this change. main pins appwrite/php-clamav at 2.0.0, which sizes every INSTREAM frame at the chunk length rather than the bytes read and loops on !feof(), so it sends roughly twice the file and desyncs the framing — the log here shows INSTREAM: Size limit reached, (requested: 247036), a length read out of file bytes. ClamAV answers with an error, the bool API reports that as a detection, and Storage deletes the upload and returns 403. Fixed in php-clamav 2.0.2; that lane is 2 failures in 19 runs on main itself. Bumping it is a separate change, not one to bury in a MongoDB entrypoint PR.