Hold mongodb at 2.2.1

[abnegate]

Reverts one pin from 2.0.0: mongodb 2.3.3 → 2.2.1. Everything else 2.0.0 shipped stays.

Why

The driver bump moves bundled libmongoc from 2.2.2 to 2.3.0, and Cloud's zero-downtime probe fails on that pairing. A read issued while a provisioned MongoDB is failing over returns 503 database_unavailable, and it still fails the probe's retry half a second later.

The probe is explicit that a single blip is expected and tolerated:

The cutover's sever step deliberately kills in-flight statements while preserving the sessions that carry them, so a read caught at that instant errors once and succeeds a moment later — the semantics every official driver gives applications by retrying idempotent reads. […] A real outage fails the retry too.

Failing the retry means the window where no primary is reachable outlasts what a client is supposed to paper over. For anything performing Mongo failovers or resizes, that is an availability regression.

Evidence

• Failed twice on appwrite-labs/cloud#5181, at a different point each run — specification resize, then manual failover. Flake does not reproduce with that shape.
• The same jobs pass on cl-1.9.5-1, which carries mongodb 2.2.1 / libmongoc 2.2.2, and on other open Cloud PRs.
• Only the Mongo path fails. The MySQL and Postgres transition suites are green on the same run.
• php --ri mongodb confirms the delta: cl-1.9.5-1 → libmongoc 2.2.2, cl-1.9.6-1 → libmongoc 2.3.0.

What this is not

This is not a controlled isolation. Proving it outright means holding everything else constant and flipping only this pin, which is exactly what this PR sets up: rebuild, re-tag CE, re-run the Cloud suite. If the probe goes green, the driver is confirmed and the libmongoc 2.3.0 change can be investigated on its own terms rather than while blocking a release chain.

Verification

Rebuilt locally: mongodb 2.2.1, libmongoc bundled version => 2.2.2 — the exact driver Cloud runs in production today.

Follow-up

Once #75 lands, the weekly updater will select 2.3.3 again — same major, newer — and it approves and merges its own PRs. This hold needs a machine-readable guard in Catalog before that happens, or the regression returns on the next scheduled run with nothing to stop it.

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

Pins the PHP MongoDB extension back to 2.2.1 to restore the bundled libmongoc 2.2.2 behavior during database failovers.

• Updates the MongoDB release label from 2.3.3 to 2.2.1.
• Updates the immutable source commit used by the Docker build.

Confidence Score: 5/5

The PR appears safe to merge based on the supplied rebuild verification and the absence of an established defect in the changed pin.

The Docker build fetches the MongoDB extension by the updated immutable commit, and the reported rebuilt image contains the intended mongodb 2.2.1 and bundled libmongoc 2.2.2 versions.

Important Files Changed

Filename	Overview
Dockerfile	Updates the MongoDB extension’s version and immutable commit pin together; no actionable defect is established by the changed lines.

_{Reviews (1): Last reviewed commit: "(fix): hold mongodb at 2.2.1" | Re-trigger Greptile}

[abnegate]

Closing — the rationale was wrong, and a controlled A/B disproves it.

With the edge checkout pinned to a single SHA (6837cc2a), both CE bases pass the DocumentsDB zero-downtime test:

	edge	CE base	mongodb	result
Arm A	6837cc2a (pinned)	cl-1.9.6-1	2.3.3	pass, 0 no elected primary events
Arm B	6837cc2a	cl-1.9.5-1	2.2.1	pass

So mongodb 2.3.3 / libmongoc 2.3.0 is not the cause. The original failures were at edge deff18b0; .github/workflows/ci.yaml in appwrite-labs/cloud checks edge out at ref: main, unpinned, and it moved four times during the investigation (5e858fe9 → deff18b0 → 6837cc2a → 74f4072f). My earlier comparison attributed an edge difference to the driver.

2.0.0 stays as released. No revert needed.