e2e: compile-gated approval seam — live-test the full self-serve link→approve→audio flow (the one leg bots cannot drive) #113

New issue

Open

opened 2026-07-12 21:53:56 +00:00 by robocub · 0 comments

robocub commented

2026-07-12 21:53:56 +00:00

Collaborator

The one hole no live scenario can reach. Discord /bridge approve is a slash-command interaction, and a bot cannot invoke an interaction (only a human client can; the self-bot route is a ToS violation we've ruled out). So no live scenario has ever driven a self-serve link all the way to a RUNNING bridge with audio — the approve step is an unbridgeable gap in the middle of the flow. Today we cover its pieces separately (Manage-Server gate = unit test; code redemption/commit = in-crate test injecting a synthetic DiscordApproval) and the real click is a once-per-change manual check.

Proposal: a compile-time-gated approval seam so the harness can fabricate the approval inside a running bridge and finally run link → pending code → (seam) approve → bridge spawns → assert audio → unlink as ONE live scenario — ideally with a FEDERATED requester (the fixture, #109), which would be the single most realistic test the suite can hold.

Design

Cargo feature test-approval-seam (default OFF). Under it only, expose a path that feeds a DiscordApproval into the existing approval_rx → handle_discord_approval channel (crates/matrix-rtc/src/mgmt.rs:111/1020) — i.e. it reuses the REAL redemption/commit machinery; it fabricates only the Discord-interaction half that handle_approve_command (crates/discord/src/puppet.rs:2473) normally produces.
Simplest transport: an operator-only mgmt command approve-test <code> <guild> compiled in ONLY under the feature (no arm exists otherwise).
Harness builds its bridge binary anyway (every scenario already runs a purpose-built binary), so it just builds with --features test-approval-seam.

Safety is the point — treat "can't reach prod" as a REQUIREMENT, not a footnote

A test-only auth bypass is safe by design, catastrophic by accident. Non-negotiables:

Compile-time gate, never runtime. The seam must NOT exist in a binary built without the feature — no env var, no config key, can bring it back. Verify: cargo build (release/deb profile) → strings/symbol check the artifact for the seam symbol = absent.
Release pipeline builds without it. Audit .forgejo/workflows/docker.yml + the deb/rpm packaging: they must never pass --features test-approval-seam. Add a CI assertion that the shipped binary lacks the seam.
Loud when present. A bridge compiled with the feature logs a prominent startup WARN: test approval seam COMPILED IN — never run this build in production, and the e2e config refuses the full-flow scenario against a binary that doesn't announce the seam (so the scenario can't silently no-op).
Belt-and-braces: gate the seam command additionally behind operator-tier auth (so even in a seam build it's not open), and keep the code path a few lines that only forward to the existing handler — no new commit logic.

What still stays manual (smaller than today)

The thin serenity slice — real interaction DISPATCH + option parsing in handle_approve_command — isn't exercised by the seam. Cover it with a synthetic-interaction unit test, and keep the once-per-change human /bridge approve click. The seam moves the manual boundary from "the entire approve leg" to "millimeters of interaction plumbing."

Payoff

First-ever live coverage of the COMPLETE self-serve journey to running audio; composes with #109 for a federated-requester end-to-end; closes the last structural blind spot after #99 + the fixture.

**The one hole no live scenario can reach.** Discord `/bridge approve` is a slash-command *interaction*, and a bot cannot invoke an interaction (only a human client can; the self-bot route is a ToS violation we've ruled out). So no live scenario has ever driven a self-serve `link` all the way to a RUNNING bridge with audio — the approve step is an unbridgeable gap in the middle of the flow. Today we cover its pieces separately (Manage-Server gate = unit test; code redemption/commit = in-crate test injecting a synthetic `DiscordApproval`) and the real click is a once-per-change manual check. **Proposal: a compile-time-gated approval seam** so the harness can fabricate the approval inside a running bridge and finally run `link → pending code → (seam) approve → bridge spawns → assert audio → unlink` as ONE live scenario — ideally with a FEDERATED requester (the fixture, #109), which would be the single most realistic test the suite can hold. ### Design - Cargo feature `test-approval-seam` (default OFF). Under it only, expose a path that feeds a `DiscordApproval` into the existing `approval_rx` → `handle_discord_approval` channel (`crates/matrix-rtc/src/mgmt.rs:111/1020`) — i.e. it reuses the REAL redemption/commit machinery; it fabricates only the Discord-interaction half that `handle_approve_command` (`crates/discord/src/puppet.rs:2473`) normally produces. - Simplest transport: an operator-only mgmt command `approve-test <code> <guild>` compiled in ONLY under the feature (no arm exists otherwise). - Harness builds its bridge binary anyway (every scenario already runs a purpose-built binary), so it just builds with `--features test-approval-seam`. ### Safety is the point — treat "can't reach prod" as a REQUIREMENT, not a footnote A test-only auth bypass is safe by design, catastrophic by accident. Non-negotiables: - **Compile-time gate, never runtime.** The seam must NOT exist in a binary built without the feature — no env var, no config key, can bring it back. Verify: `cargo build` (release/deb profile) → `strings`/symbol check the artifact for the seam symbol = absent. - **Release pipeline builds without it.** Audit `.forgejo/workflows/docker.yml` + the deb/rpm packaging: they must never pass `--features test-approval-seam`. Add a CI assertion that the shipped binary lacks the seam. - **Loud when present.** A bridge compiled with the feature logs a prominent startup `WARN: test approval seam COMPILED IN — never run this build in production`, and the e2e config refuses the full-flow scenario against a binary that doesn't announce the seam (so the scenario can't silently no-op). - **Belt-and-braces:** gate the seam command additionally behind operator-tier auth (so even in a seam build it's not open), and keep the code path a few lines that only forward to the existing handler — no new commit logic. ### What still stays manual (smaller than today) The thin serenity slice — real interaction DISPATCH + option parsing in `handle_approve_command` — isn't exercised by the seam. Cover it with a synthetic-interaction unit test, and keep the once-per-change human `/bridge approve` click. The seam moves the manual boundary from "the entire approve leg" to "millimeters of interaction plumbing." ### Payoff First-ever live coverage of the COMPLETE self-serve journey to running audio; composes with #109 for a federated-requester end-to-end; closes the last structural blind spot after #99 + the fixture.