mx.sendMessage(roomId, ...).catch(() => undefined) discards any send failure from a native rich-toast quick reply (network error, no permission to post, room become read-only, etc.) with no toast, no re-open of the reply box, nothing. The user believes the reply was sent and only discovers it wasn't when they later look at the room. (The follow-up item about the reply target being wrong for threads/invites is already tracked in LOTUS_TODO.md; this is the separate, still-open "errors are invisible" issue even once the target is fixed.)
How to trigger
Use the Windows toast inline quick-reply while offline or against a room you've lost send permission in.
Suggested fix
On rejection, surface an in-app toast (createErrorToast) so the failure isn't silent, and/or route back through showOsNotification/a fresh native toast so the user can retry.
Filed from the September 2026 client audit (branch lotus @ 4bea4895).
**Severity:** low · **Type:** ux · **Confidence:** high
**Location:** `src/app/hooks/useTauriToastActions.ts:35-38`
### Problem
`mx.sendMessage(roomId, ...).catch(() => undefined)` discards any send failure from a native rich-toast quick reply (network error, no permission to post, room become read-only, etc.) with no toast, no re-open of the reply box, nothing. The user believes the reply was sent and only discovers it wasn't when they later look at the room. (The follow-up item about the reply target being wrong for threads/invites is already tracked in `LOTUS_TODO.md`; this is the separate, still-open "errors are invisible" issue even once the target is fixed.)
### How to trigger
Use the Windows toast inline quick-reply while offline or against a room you've lost send permission in.
### Suggested fix
On rejection, surface an in-app toast (`createErrorToast`) so the failure isn't silent, and/or route back through `showOsNotification`/a fresh native toast so the user can retry.
---
_Filed from the September 2026 client audit (branch `lotus` @ 4bea4895)._
jared
added this to the Audit 2026-09 · Medium & Low milestone 2026-09-12 01:51:30 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Severity: low · Type: ux · Confidence: high
Location:
src/app/hooks/useTauriToastActions.ts:35-38Problem
mx.sendMessage(roomId, ...).catch(() => undefined)discards any send failure from a native rich-toast quick reply (network error, no permission to post, room become read-only, etc.) with no toast, no re-open of the reply box, nothing. The user believes the reply was sent and only discovers it wasn't when they later look at the room. (The follow-up item about the reply target being wrong for threads/invites is already tracked inLOTUS_TODO.md; this is the separate, still-open "errors are invisible" issue even once the target is fixed.)How to trigger
Use the Windows toast inline quick-reply while offline or against a room you've lost send permission in.
Suggested fix
On rejection, surface an in-app toast (
createErrorToast) so the failure isn't silent, and/or route back throughshowOsNotification/a fresh native toast so the user can retry.Filed from the September 2026 client audit (branch
lotus@4bea4895).