#99 - e2e: DM/invite lifecycle coverage — E2EE DMs, restart races, cooldown semantics (gaps exposed by #96/#97) - dark/nether-voicebridge

robocub commented

2026-07-12 04:17:47 +00:00

Collaborator

The first real self-serve user surfaced two DM-path failures the 20-scenario suite never exercises (#96 wrong-address stranding, #97 restart-window double-processing → auto-decline). The suite covers the happy DM path (create/greet/commands, invite-gate rejects) but only with LOCAL, PLAINTEXT, steady-state DMs. Gaps, in priority order:

E2EE DM actor (biggest blind spot). Real clients (Element) often create DMs with encryption ON — dau's first DM was E2EE. Whether the mgmt bot can DECRYPT commands in an encrypted DM has never been tested anywhere (harness DMs are raw-CS-API plaintext; the bot's reply-side encryption is believed to work via the SDK, receive-side is unknown). Needs a crypto-capable test actor — a small matrix-sdk-based client in the harness (heavier than the raw-CS masquerade actors, but reusable). Scenario: encrypted DM → greeting decryptable → help answered → link flow end-to-end.
Offline/restart invite handling. Scenario: send the DM invite while the bridge process is DOWN, then start it — assert exactly ONE accept, greeting delivered, NO decline (the #97 regression test at the scenario level; the dedupe/cooldown-after-join logic itself should also get in-crate tests with the #97 fix).
Invite-cooldown semantics (unit tier). #89a's cooldown must distinguish "N distinct invites from one sender" (rate-limit) from "the same invite seen twice" (dedupe, never decline) — pin with in-crate tests once #97 lands.
Federated-inviter caveat (document, don't build). dau's failures involved federation (tinier.town); the harness can't mint remote users. Note the limitation in the testing design doc rather than pretending local invites cover it.

Suggested order: #97 fix + its unit tests first, then the offline-invite scenario (cheap — one process-start reordering), then the E2EE actor (the real investment).

The first real self-serve user surfaced two DM-path failures the 20-scenario suite never exercises (#96 wrong-address stranding, #97 restart-window double-processing → auto-decline). The suite covers the happy DM path (create/greet/commands, invite-gate rejects) but only with LOCAL, PLAINTEXT, steady-state DMs. Gaps, in priority order: 1. **E2EE DM actor (biggest blind spot).** Real clients (Element) often create DMs with encryption ON — dau's first DM was E2EE. Whether the mgmt bot can DECRYPT commands in an encrypted DM has never been tested anywhere (harness DMs are raw-CS-API plaintext; the bot's reply-side encryption is believed to work via the SDK, receive-side is unknown). Needs a crypto-capable test actor — a small matrix-sdk-based client in the harness (heavier than the raw-CS masquerade actors, but reusable). Scenario: encrypted DM → greeting decryptable → `help` answered → `link` flow end-to-end. 2. **Offline/restart invite handling.** Scenario: send the DM invite while the bridge process is DOWN, then start it — assert exactly ONE accept, greeting delivered, NO decline (the #97 regression test at the scenario level; the dedupe/cooldown-after-join logic itself should also get in-crate tests with the #97 fix). 3. **Invite-cooldown semantics (unit tier).** #89a's cooldown must distinguish "N distinct invites from one sender" (rate-limit) from "the same invite seen twice" (dedupe, never decline) — pin with in-crate tests once #97 lands. 4. **Federated-inviter caveat (document, don't build).** dau's failures involved federation (tinier.town); the harness can't mint remote users. Note the limitation in the testing design doc rather than pretending local invites cover it. Suggested order: #97 fix + its unit tests first, then the offline-invite scenario (cheap — one process-start reordering), then the E2EE actor (the real investment).

robocub referenced this issue

2026-07-12 04:43:34 +00:00

mgmt: restart-window invite double-processing can auto-DECLINE a legitimate DM invite (#89a cooldown misfire) #97

robocub referenced this issue

2026-07-12 04:53:45 +00:00

e2e: #99 implementation — E2EE DM actor + invite-lifecycle scenarios (parallel-instance handoff) #100

robocub referenced this issue from a commit

2026-07-12 05:24:17 +00:00

feat(e2e): #99 invite/DM lifecycle coverage — E2EE DM actor + 3 scenarios

robocub referenced this issue

2026-07-12 05:26:16 +00:00

e2e: #99 implementation — E2EE DM actor + invite-lifecycle scenarios (parallel-instance handoff) #100

robocub referenced this issue from a commit

2026-07-12 05:49:15 +00:00

feat(e2e): #99 invite/DM lifecycle coverage — E2EE DM actor + 3 scenarios

robocub commented

2026-07-12 06:16:17 +00:00

Author

Collaborator

#99 implemented on `feat/99-invite-dm-scenarios` — live evidence (2026-07-12, staging, compressed profile)

Suite 20 → 23. Runner: clippy -D warnings clean, cargo test --workspace --locked green (331 tests).

1. `mgmt_dm_e2ee` — PASS 11.5 s (first try, pre-alpha.25 bridge; 10.5 s re-run post-alpha.25)

New crypto actor MatrixCryptoDmClient (full matrix-sdk client, ephemeral server-minted device, in-memory stores, logout-on-teardown). Encrypted DM → bot auto-joins → greeting decryptable → help round-trips through encryption both ways → transport proof: every m.room.message crossed the wire as m.room.encrypted (TimelineEventKind::Decrypted vs PlainText doubles as the wire check), traffic asserted both directions.

2. `mgmt_invite_offline` — shipped Pass, not KnownFail (deviation from the brief, evidence-driven)

Pre-fix bridge, mgmt_cooldown_secs = 60 ARMED via the new start_with_management_opts extra-limits seam (the standing harness block leaves it unset — exactly why 20 scenarios never reproduced #97a): unexpected_pass 21.4 s — exactly ONE accept, ZERO declines, bot stayed joined (verified in artifacts). The #97a trigger needs the seconds-long federated-join redelivery window; a same-server inviter (all the harness can mint) doesn't produce it. Re-classified per the runner's own unexpected_pass recommendation; the scenario stays as the post-fix-contract regression guard. Federation limitation documented in the testing-design doc. Post-alpha.25: pass 19.7 s.

3. `mgmt_dm_pending_reap` — KnownFail{#97}, still failing post-alpha.25 (see #100 comment)

Pre-fix: reap reproduced deterministically — the compressed #89b sweep reaped the fresh operator-msg DM ~100 ms after creation, before the message could even be sent (403 sender's membership \leave` is not `join``); room-id-correlated in artifacts. Post-alpha.25 (3 runs): still known_fail — two residual modes, detail + mechanism posted on #100.

Bonus finding while building it: the SDK's create_dm mints operator-msg DMs encrypted, so the reap-scenario target is a crypto client — coverage of the msg outreach path is E2EE end-to-end.

4. Regression (bridge_proc seam changes)

mgmt_self_serve_link pass 61.4 s · room_misconfig_notice pass 29.3 s.

Branch is rebased onto master 1a769f9 (alpha.25), runner-green. Awaiting the operator's merge word.

## #99 implemented on `feat/99-invite-dm-scenarios` — live evidence (2026-07-12, staging, compressed profile) **Suite 20 → 23.** Runner: clippy `-D warnings` clean, `cargo test --workspace --locked` green (331 tests). ### 1. `mgmt_dm_e2ee` — **PASS 11.5 s** (first try, pre-alpha.25 bridge; 10.5 s re-run post-alpha.25) New crypto actor `MatrixCryptoDmClient` (full matrix-sdk client, ephemeral server-minted device, in-memory stores, logout-on-teardown). Encrypted DM → bot auto-joins → greeting **decryptable** → `help` round-trips through encryption both ways → transport proof: every `m.room.message` crossed the wire as `m.room.encrypted` (`TimelineEventKind::Decrypted` vs `PlainText` doubles as the wire check), traffic asserted both directions. ### 2. `mgmt_invite_offline` — shipped **Pass**, not KnownFail (deviation from the brief, evidence-driven) Pre-fix bridge, `mgmt_cooldown_secs = 60` ARMED via the new `start_with_management_opts` extra-limits seam (the standing harness block leaves it unset — exactly why 20 scenarios never reproduced #97a): **unexpected_pass 21.4 s** — exactly ONE accept, ZERO declines, bot stayed joined (verified in artifacts). The #97a trigger needs the seconds-long federated-join redelivery window; a same-server inviter (all the harness can mint) doesn't produce it. Re-classified per the runner's own `unexpected_pass` recommendation; the scenario stays as the post-fix-contract regression guard. Federation limitation documented in the testing-design doc. Post-alpha.25: pass 19.7 s. ### 3. `mgmt_dm_pending_reap` — **KnownFail{#97}, still failing post-alpha.25** (see #100 comment) Pre-fix: reap reproduced deterministically — the compressed #89b sweep reaped the fresh operator-`msg` DM **~100 ms after creation**, before the message could even be sent (403 `sender's membership \`leave\` is not \`join\``); room-id-correlated in artifacts. Post-alpha.25 (3 runs): still known_fail — two residual modes, detail + mechanism posted on #100. Bonus finding while building it: the SDK's `create_dm` mints operator-`msg` DMs **encrypted**, so the reap-scenario target is a crypto client — coverage of the `msg` outreach path is E2EE end-to-end. ### 4. Regression (bridge_proc seam changes) `mgmt_self_serve_link` pass 61.4 s · `room_misconfig_notice` pass 29.3 s. Branch is rebased onto master `1a769f9` (alpha.25), runner-green. **Awaiting the operator's merge word.**

robocub referenced this issue

2026-07-12 06:16:43 +00:00

e2e: #99 implementation — E2EE DM actor + invite-lifecycle scenarios (parallel-instance handoff) #100

robocub referenced this issue from a commit

2026-07-12 06:37:29 +00:00

feat(e2e): #99 invite/DM lifecycle coverage — E2EE DM actor + 3 scenarios (#99)

robocub commented

2026-07-12 06:37:55 +00:00

Author

Collaborator

Merged to master with the operator's word: d2503b6 (#99 squash — suite 20 → 23) + 26605c9 (nightly e2e identity fix: the workflow still masqueraded the deactivated pre-#96 @nether-voicebridge_bot; both env blocks now use nether-voicebridge_e2e, so tomorrow's 06:00 nightly runs with the right identity).

Remaining follow-up lives on #100: mgmt_dm_pending_reap stays KnownFail{#97} until the alpha.25 residuals (store-lag reap race + cold-DM first-message UTD) are fixed in crates/matrix-rtc — then flip to Pass and re-run live. Closing this issue: all four #99 deliverables are on master with live evidence above.

Merged to master with the operator's word: `d2503b6` (#99 squash — suite 20 → 23) + `26605c9` (nightly e2e identity fix: the workflow still masqueraded the deactivated pre-#96 `@nether-voicebridge_bot`; both env blocks now use `nether-voicebridge_e2e`, so tomorrow's 06:00 nightly runs with the right identity). Remaining follow-up lives on #100: `mgmt_dm_pending_reap` stays `KnownFail{#97}` until the alpha.25 residuals (store-lag reap race + cold-DM first-message UTD) are fixed in `crates/matrix-rtc` — then flip to `Pass` and re-run live. Closing this issue: all four #99 deliverables are on master with live evidence above.

robocub closed this issue

2026-07-12 06:37:55 +00:00

robocub referenced this issue

2026-07-12 06:37:55 +00:00

e2e: #99 implementation — E2EE DM actor + invite-lifecycle scenarios (parallel-instance handoff) #100

robocub referenced this issue

2026-07-12 07:30:09 +00:00

mgmt: restart-window invite double-processing can auto-DECLINE a legitimate DM invite (#89a cooldown misfire) #97

robocub referenced this issue

2026-07-12 07:30:09 +00:00

mgmt: v12 (domainless) room ids rejected by link shape-check; first-contact joins need a via hint #103

robocub referenced this issue

2026-07-12 07:30:09 +00:00

e2e: #99 implementation — E2EE DM actor + invite-lifecycle scenarios (parallel-instance handoff) #100

robocub referenced this issue

2026-07-12 07:37:10 +00:00

e2e: #99 implementation — E2EE DM actor + invite-lifecycle scenarios (parallel-instance handoff) #100

robocub referenced this issue

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

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

robocub referenced this issue from a commit

2026-07-26 04:38:07 +00:00

release: 0.3.1 — one-way-deafness fix; e2e: hold the reaper off the steal scenario's phantoms (#127, #24)

Rows
Columns

e2e: DM/invite lifecycle coverage — E2EE DMs, restart races, cooldown semantics (gaps exposed by #96/#97) #99

#99 implemented on feat/99-invite-dm-scenarios — live evidence (2026-07-12, staging, compressed profile)

1. mgmt_dm_e2ee — PASS 11.5 s (first try, pre-alpha.25 bridge; 10.5 s re-run post-alpha.25)

2. mgmt_invite_offline — shipped Pass, not KnownFail (deviation from the brief, evidence-driven)

3. mgmt_dm_pending_reap — KnownFail{#97}, still failing post-alpha.25 (see #100 comment)

4. Regression (bridge_proc seam changes)

#99 implemented on `feat/99-invite-dm-scenarios` — live evidence (2026-07-12, staging, compressed profile)

1. `mgmt_dm_e2ee` — PASS 11.5 s (first try, pre-alpha.25 bridge; 10.5 s re-run post-alpha.25)

2. `mgmt_invite_offline` — shipped Pass, not KnownFail (deviation from the brief, evidence-driven)

3. `mgmt_dm_pending_reap` — KnownFail{#97}, still failing post-alpha.25 (see #100 comment)