5.1 KiB
Parity — matrix-synapse
Phase-2 P2 mapping table. The recipe-maintainer corpus for matrix-synapse is shell scripts targeting a persistent instance (cctest.autonomic.zone) with pre-seeded admin users + bloated state; they exercise abra.sh helper commands and synapse_auto_compressor flows. The cc-ci adaptation re-expresses the intent (matrix-synapse's defining behavior — registration, rooms, messages, federation) in Python tests adapted to the ephemeral per-run-deploy model.
| recipe-maintainer file | cc-ci file | what's verified | status |
|---|---|---|---|
| (no health_check.py in the recipe-maintainer corpus) | tests/matrix-synapse/custom/test_health_check.py |
HTTP 200 + JSON document from /_matrix/client/versions (the synapse client API). |
Phase-2 health_check (aligned with the parity-port convention; the corpus has no health_check.py to port from). |
recipe-info/matrix-synapse/tests/compress_state.sh |
(deferred to Q4 follow-up — synapse_auto_compressor + state-group bloat) | The original creates state groups WITHOUT edges (full snapshots — Synapse's bloat pattern), runs the synapse_auto_compressor, asserts row counts drop. Requires per-run admin user pre-seeded + a long-running synapse + access to the synapse_auto_compressor binary. | deferred (operational complexity; needs custom install_steps.sh + admin user pre-seeding) |
recipe-info/matrix-synapse/tests/test_complexity_limit.sh |
(deferred to Q4 follow-up — rate-limit behaviour) | Exercises Synapse's complexity-limit rejection of huge events. | deferred (load-test class; needs many-event setup) |
recipe-info/matrix-synapse/tests/test_purge.sh |
(deferred to Q4 follow-up — admin purge commands) | Tests the abra.sh db purge_history, db purge_room etc. helpers. Operational tests against the recipe's helper shell wrappers. |
deferred (recipe-helper-script tests, not synapse-behavior tests; orthogonal to Phase-2 P3) |
The recipe-maintainer corpus shell-script tests are operational regression tests for synapse's state-management subsystem and the recipe's admin helpers. The cc-ci Phase-2 lens is recipe functionality — does the recipe deploy a working Matrix server. Those operational tests are tracked as Q4 follow-up + DECISIONS.md (technical reason: they need pre-seeded admin + long- running state + helper-script execution scaffold). The matrix-synapse defining behavior IS covered by the recipe-specific tests below.
Recipe-specific tests (Phase-2 P3, ≥2 beyond parity)
Plan §4.3 explicitly: "matrix-synapse — register two users (admin API); one sends a room message, the other reads it; media upload→download; /_matrix/federation/v1/version reachable." Three specific tests landed (beyond parity health_check):
| cc-ci file | what's verified | rationale |
|---|---|---|
tests/matrix-synapse/custom/test_federation_version.py |
GET /_matrix/federation/v1/version → 200, JSON with server.name == "Synapse", non-empty server.version. |
Plan §4.3 prescribed. Federation discovery endpoint — the recipe's "is this a real Synapse, federation-ready" surface. Non-vacuous: a Dendrite or misconfigured federation subsystem fails. |
tests/matrix-synapse/custom/test_register_and_message.py |
Plan §4.3 prescribed create-and-read-back. Reads the abra-generated registration shared secret from the synapse container; registers two users (alice + bob) via /_synapse/admin/v1/register (HMAC-SHA1 nonce flow); both login via /_matrix/client/v3/login; alice creates a private_chat room; invites bob; bob joins; alice sends a uniquely-marked m.room.message; bob reads the room's messages and finds the marker. |
The canonical Matrix create-and-read-back, exercising registration + login + room create/invite/join + send/receive across the full client API. Non-vacuous: each step fails at the level it's broken (admin API, login, room ops, send/receive); marker assertion confirms the message actually round-tripped across two users. |
Media upload/download deferred — would add a fourth specific test (media_upload_roundtrip)
using /_matrix/media/v3/upload + /_matrix/media/v3/download/<server>/<media_id>. Not in this
Q4.1 pass; tracked for follow-up.
Backup data-integrity (P4)
Exercised by the Phase-1d/1e lifecycle overlays
(tests/matrix-synapse/{test_backup.py,test_restore.py,ops.py} — the marker is a ci_marker
row in the synapse postgres DB, written via psql in the db service; survives backup/restore
via the recipe's pg_backup.sh DB-dump hook).
Playwright (P6)
The base matrix-synapse recipe has no browser UI — element-web is a separate recipe that
front-ends a Matrix homeserver. So P6 is N/A for the base recipe; the functional surface is the
HTTP/REST client + federation API which the tests above cover. If element-web is later enrolled
as a Phase-2 recipe, its Playwright tests would consume matrix-synapse as a DEPS-declared
homeserver.
Non-ports
The three shell-script parity tests are documented above as deferred to Q4 follow-up with a technical reason (operational complexity vs ephemeral per-run model). No silent omissions.