| fix(docker): make MongoDB replica set init idempotent (#29515) ## Problem The replica-set init script in the shared MongoDB Dockerfile (`docker/mongodb_replica/Dockerfile`, used by both the `mongo` v4 and `mongo6` services in `docker/docker-compose.yml`) uses the following loop to wait for mongod to become ready before seeding the replica set: ```sh until ($MONGO_COMMAND admin --port $MONGO_REPLICA_PORT --eval "rs.initiate(...)"); do sleep 1; done ``` On first boot this works correctly: `rs.initiate()` succeeds, mongosh exits 0, and the loop terminates. However, when the container is restarted (`docker restart`, `docker compose up -d` after a stop, host reboot, etc.) with its writable layer still intact — which is the default, since neither service declares a named/bind volume for `/data/db` — the replica set config already exists in the data directory. `rs.initiate()` then returns an `AlreadyInitialized` error (code 23) with a non-zero exit status. The `until` loop treats that as "not ready yet" and retries every second, **forever**. Each iteration: - Spawns a fresh mongosh process (heavy V8/JS startup, especially on arm64). - Opens ~5 TCP connections to mongod for topology discovery. In a local workspace that had been running for ~19 hours, this had accumulated **~309,000 connections** and was steady-state pinning ~32% of a single CPU core (visible at the host level as the Colima/Lima VM sitting at load average ~1.0). ## Fix Wrap the `rs.initiate(...)` call in a JS `try`/`catch` that swallows only the `AlreadyInitialized` case (matched by either `codeName` or numeric code `23`). The expression then exits 0 and the `until` loop terminates after a single successful attempt. Real startup errors (connection refused while mongod is still booting, etc.) still surface as shell failures from mongo/mongosh itself and are retried exactly as before. Any *other* MongoDB error is re-thrown and remains visible in the logs. Applies to both `mongo` (v4) and `mongo6` services since they share this Dockerfile via the `MONGO_VERSION` build arg. Both `mongo` and `mongosh` support `try`/`catch` with `throw`, so the same JS expression works for either value of `MONGO_COMMAND`. ## Verification Rebuilt both images and exercised the failure mode locally: 1. **Fresh boot (`mongo6`)**: single `replSetInitiate` attempt, `REPLICA SET ONLINE` printed once, container reports `healthy`, steady-state CPU ~1% (with healthcheck-driven mongosh spawns every 5 s). 2. **Restart with existing replica-set state (`mongo6`)**: this is the bug scenario. After the fix, a single `replSetInitiate` attempt is made, the `AlreadyInitialized` error is caught, `REPLICA SET ONLINE` is printed once, and the loop exits immediately. PID count stays steady (no process leak). Connection IDs grow only at the expected healthcheck rate. 3. **`mongo` (v4)**: same behavior — the v4 shell prints the error object to stdout as text but the `throw` is still caught, so the script exits 0 and the loop terminates. Container reports `healthy`. Without this fix, step 2 continues spawning a mongosh every second indefinitely. ## Risk Minimal: the only behavioral change is that an `AlreadyInitialized` error no longer triggers a retry. Every other code path (successful init, transient connection failure during mongod startup, unexpected MongoDB error) is preserved. | 6 months ago |
| docs: point the 7.x documentation at its own branch (#29827) ## Summary Companion to prisma/prisma#29826, which adds the reciprocal signpost on the default branch. **A banner at the top of the README** says which line this branch carries, and where the default branch went. Readers arrive here from links and search results as often as from the repository root, so "you are on the 7.x line" is worth saying in place. **Twelve self-links move from `/main/` to `/v7/`.** Written as `blob/main` and `tree/main`, they now resolve into the Prisma Next tree on the default branch, so the contribution guide, the code of conduct, the workflow files and the integration-test examples all lead somewhere unrelated to this code. All twelve are `github.com/prisma/prisma` self-links; links to other repositories are untouched. **The tests badge** used the legacy `workflows/CI/badge.svg` form, which reports the *default* branch's status for a workflow named `CI` — and there are no such runs there, since `test.yml` triggers on this branch. It now names `test.yml` explicitly and filters on `v7`: ```diff -[](…?query=branch%3Amain) +[](…?query=branch%3Av7) ``` **`TESTING.md` linked `release-ci.yml`**, which has not existed for some time and is now `v7-release.yml` following prisma/prisma#29823. The link text follows the workflow's current display name. ## A note on CI cost Three of the four files are root-level `*.md` and so match `test.yml`'s `paths-ignore`. `docker/docker-compose.yml` does not, and its change is a single comment line — so this documentation-only PR will run the full test matrix. Worth knowing rather than being surprised by; I kept the fix rather than leaving one stale link behind for tidiness' sake. ## Testing performed - Confirmed `CONTRIBUTING.md` and `CODE_OF_CONDUCT.md` exist on this branch, so the repointed links resolve. - Swept all four files afterwards for surviving `/main/` self-links, `release-ci.yml` references and `branch%3Amain` queries: the only match is the banner's own deliberate link to the default branch. - Documentation is not exercised by CI; the links are the thing to spot-check on the rendered page. ## Checklist - [x] All commits are signed off per the DCO. - [x] The change is scoped to one logical concern. Signed-off-by: Alexey Orlenko's AI Agent <robot@aqrln.net> | 3 months ago |