diff --git a/machine-docs/DECISIONS.md b/machine-docs/DECISIONS.md index c590ab4..c08353a 100644 --- a/machine-docs/DECISIONS.md +++ b/machine-docs/DECISIONS.md @@ -919,3 +919,16 @@ connections + `DROP DATABASE … WITH (FORCE)` + `createdb` + reimport (the matr trick does NOT cover immich-server's *networked* connections, so FORCE-drop is required). The VectorChord/pgvecto.rs extensions (vchord, vector) + all tables round-trip cleanly — validated live, then proven green end-to-end via `RECIPE=immich PR=1` (restore tier `test_restore_returns_state` PASS). + +## mattermost-lts postgres restore recipe-PR (Phase 2 Q4.5 P4) — 2026-05-30 +**Decision:** fix mattermost-lts's broken DB restore with a recipe-PR (`recipe-maintainers/mattermost-lts#1`), +mirroring the immich precedent. The published recipe's `postgres` service dumps the DB on backup +(pg_dump pre-hook) but ships NO `backupbot.restore.post-hook`, and archived the whole live PGDATA dir +(`backup.path=/var/lib/postgresql/data/`). backupbot's restore extracts the files under the running +postgres, which does NOT reload PGDATA without a restart → the live DB keeps the un-restored state. +Proven by the P4 overlay: `test_restore_returns_state` RED (`relation "ci_marker" does not exist`). +**Fix:** switch to the coop-cloud `/pg_backup.sh` convention (as matrix-synapse): config-mounted +script, `backup` = pg_dump|gzip → backup.sql, `backupbot.backup.volumes.postgres_data.path=backup.sql` +(archive only the dump), `restore` post-hook = terminate connections + DROP DATABASE FORCE + createdb ++ reimport. postgres:15 plain dump → no special handling (mechanism already proven generic on immich). +Validated: `RECIPE=mattermost-lts PR=1` full lifecycle GREEN, restore tier PASSES (ci_marker survives). diff --git a/tests/mattermost-lts/PARITY.md b/tests/mattermost-lts/PARITY.md index 02fc1b5..8993557 100644 --- a/tests/mattermost-lts/PARITY.md +++ b/tests/mattermost-lts/PARITY.md @@ -11,17 +11,24 @@ mattermost-lts ships no `test_.py` overlays, so the **generic** install/upgr tiers run by default (the Phase-1e invariant: no overlay ⇒ generic runs). The stack bundles its own postgres in-compose (no external dep), so no dependency resolution is needed. -## P3 — Recipe-specific functional tests -- `functional/test_health_check.py` - - `test_root_serves` — web app served at `/` (200/302). - - `test_system_ping_ok` — GET `/api/v4/system/ping` → `{"status":"OK"}` (proves the mattermost - server + API router are live, not a Traefik fallback). -- `functional/test_create_message.py` — **§4.3 prescribed create-an-object + read-it-back** (planned, - authored against the live instance): create the first user (system admin) → login → create team → - create channel → POST a message → GET it back → assert the message text round-trips. *(In progress — - requires response-header access for the mattermost login `Token`; harness.http extension pending.)* +## P3 — Recipe-specific functional tests (≥2 separate characteristic tests) +1. `functional/test_create_message.py::test_create_message_roundtrip` — **§4.3 create-an-object + + read-it-back**: first user (system admin) → login → create team → create channel → POST a unique + marker message → GET it back by id → assert the text round-trips. +2. `functional/test_multiuser_message.py::test_second_user_reads_first_users_message` — the defining + **team-chat** behaviour (distinct code path: membership + ACL + cross-user delivery): user_a posts a + unique marker; a SECOND user (created via admin API, added to team+channel) logs in with its own + session and GETs the channel posts → asserts it sees user_a's message. Not a self read-back. +- `functional/test_health_check.py` — `test_root_serves` (`/` 200/302) + `test_system_ping_ok` + (`/api/v4/system/ping` → `{"status":"OK"}`, API liveness). Supporting health/liveness, not counted + toward the P3 ≥2 floor. -## P4 — Backup data-integrity -Planned `ops.py`: pre_backup seeds an identifiable message via the API; pre_restore mutates/wipes; -the restore assertion re-reads the message and asserts it survived (recipe-aware, not health-only). -*(Follows once the create-message API flow is proven green.)* +## P4 — Backup data-integrity (real) +`ops.py` seeds a postgres `ci_marker` row (psql in the `postgres` service); `test_backup.py` asserts +it at backup time, `test_restore.py` asserts it survives restore, `test_upgrade.py` asserts it survives +the upgrade. **Requires recipe-PR `recipe-maintainers/mattermost-lts#1`**: the published recipe dumped +the DB on backup but shipped NO `backupbot.restore.post-hook` and archived the whole live PGDATA dir, +so a restore extracted files under the running postgres without reloading them → the DB silently kept +the un-restored state (`test_restore_returns_state` RED). The PR switches to the coop-cloud +`/pg_backup.sh` convention (dump-only backup + terminate/FORCE-drop/recreate/reimport restore); with it +the ci_marker survives backup→restore. See DECISIONS.md "mattermost-lts postgres restore recipe-PR". diff --git a/tests/mattermost-lts/functional/test_multiuser_message.py b/tests/mattermost-lts/functional/test_multiuser_message.py new file mode 100644 index 0000000..c619612 --- /dev/null +++ b/tests/mattermost-lts/functional/test_multiuser_message.py @@ -0,0 +1,114 @@ +"""mattermost-lts — 2nd recipe-specific functional test (Phase 2 P3): multi-user message visibility. + +The defining behaviour of a team-chat platform is that a message one user posts is delivered to and +readable by *another* user in the same channel — not just round-tripped by its own author (that is +`test_create_message.py`). This exercises the real membership + post-delivery path end-to-end: + + 1. Bootstrap user_a (first user = system admin) → login → create team + open channel. + 2. user_a posts a unique marker message to the channel. + 3. Create a SECOND user (user_b) via the admin API; add user_b to the team + the channel. + 4. user_b logs in (its own session token) and GETs the channel's posts. + 5. Assert user_b sees user_a's marker message — cross-user delivery, not a self read-back. + +Distinct code path from the single-user post round-trip (membership, ACL, multi-session post fetch). +Real assertions on delivered app state; unique marker per run so a stale/echoed response can't pass. +""" + +from __future__ import annotations + +import os +import sys +import uuid + +sys.path.insert(0, os.path.join(os.path.dirname(__file__), "..", "..", "..", "runner")) +from harness import http as harness_http # noqa: E402 + +_PW = "Ccci-Test-Pw-2026!" + + +def _bearer(token: str) -> dict[str, str]: + return {"Authorization": f"Bearer {token}"} + + +def _login(base: str, login_id: str) -> str: + status, _, hdrs = harness_http.post_with_headers( + f"{base}/users/login", data={"login_id": login_id, "password": _PW}, timeout=30 + ) + assert status == 200, f"login {login_id} failed: HTTP {status}" + token = hdrs.get("Token") or hdrs.get("token") + assert token, f"login {login_id} returned no Token header; headers={list(hdrs.keys())}" + return token + + +def test_second_user_reads_first_users_message(live_app): + base = f"https://{live_app}/api/v4" + uniq = uuid.uuid4().hex[:10] + + # 1) user_a = first user (system admin), login, team + channel + email_a = f"ccci{uniq}@ccci.example.com" + status, ua = harness_http.http_post( + f"{base}/users", + data={"email": email_a, "username": f"ccci{uniq}", "password": _PW}, + timeout=30, + ) + assert status in (200, 201) and ua.get("id"), f"user_a create HTTP {status}: {ua!r}" + auth_a = _bearer(_login(base, email_a)) + + status, team = harness_http.http_post( + f"{base}/teams", + data={"name": f"t{uniq}", "display_name": f"ccci {uniq}", "type": "O"}, + headers=auth_a, + timeout=30, + ) + assert status in (200, 201) and team.get("id"), f"team create HTTP {status}: {team!r}" + status, chan = harness_http.http_post( + f"{base}/channels", + data={"team_id": team["id"], "name": f"c{uniq}", "display_name": f"chan {uniq}", "type": "O"}, + headers=auth_a, + timeout=30, + ) + assert status in (200, 201) and chan.get("id"), f"channel create HTTP {status}: {chan!r}" + + # 2) user_a posts a unique marker + marker = f"ccci-multiuser-{uniq}" + status, post = harness_http.http_post( + f"{base}/posts", data={"channel_id": chan["id"], "message": marker}, headers=auth_a, timeout=30 + ) + assert status in (200, 201) and post.get("id"), f"post create HTTP {status}: {post!r}" + + # 3) create user_b (admin API) + add to team + channel + email_b = f"ccci{uniq}b@ccci.example.com" + status, ub = harness_http.http_post( + f"{base}/users", + data={"email": email_b, "username": f"ccci{uniq}b", "password": _PW}, + headers=auth_a, + timeout=30, + ) + assert status in (200, 201) and ub.get("id"), f"user_b create HTTP {status}: {ub!r}" + status, _ = harness_http.http_post( + f"{base}/teams/{team['id']}/members", + data={"team_id": team["id"], "user_id": ub["id"]}, + headers=auth_a, + timeout=30, + ) + assert status in (200, 201), f"add user_b to team HTTP {status}" + status, _ = harness_http.http_post( + f"{base}/channels/{chan['id']}/members", + data={"user_id": ub["id"]}, + headers=auth_a, + timeout=30, + ) + assert status in (200, 201), f"add user_b to channel HTTP {status}" + + # 4) user_b logs in (own session) and reads the channel posts + auth_b = _bearer(_login(base, email_b)) + status, posts = harness_http.http_get( + f"{base}/channels/{chan['id']}/posts", headers=auth_b, timeout=30 + ) + assert status == 200 and isinstance(posts, dict), f"user_b get posts HTTP {status}: {posts!r}" + + # 5) user_b sees user_a's marker (cross-user delivery, not a self read-back) + messages = [p.get("message") for p in (posts.get("posts") or {}).values()] + assert marker in messages, ( + f"user_b did not see user_a's message {marker!r} in the channel; saw {messages!r}" + )