handleScheduleClick builds a full IContent — formatted_body, m.mentions, and the m.in_reply_to/thread relation from the active reply draft — but the modal only accepts initialBody?: string and rebuilds { body, msgtype: 'm.text' } from a plain textarea. Everything except the plain body is discarded. handleScheduled then clears the reply draft and the composer, so a user who was composing a formatted reply and chose "schedule" loses the reply target and all markdown with no warning. (The docs acknowledge this only for the edit flow, not for the initial schedule.)
How to trigger
Reply to a message, type **bold** @someone, click Schedule, send. The delivered message is unformatted, unthreaded, un-mentioning plain text.
Suggested fix
Pass the whole IContent through the modal (letting the textarea edit only body, re-deriving formatted_body or dropping the rich fields only when the body was edited) and preserve m.relates_to/m.mentions.
Filed from the September 2026 client audit (branch lotus @ 4bea4895).
**Severity:** medium · **Type:** bug · **Confidence:** high
**Location:** `src/app/features/room/RoomInput.tsx:646-704` (`buildCurrentTextContent`), `:1451-1456`, `src/app/features/room/ScheduleMessageModal.tsx:34-36,127`
### Problem
`handleScheduleClick` builds a full `IContent` — `formatted_body`, `m.mentions`, and the `m.in_reply_to`/thread relation from the active reply draft — but the modal only accepts `initialBody?: string` and rebuilds `{ body, msgtype: 'm.text' }` from a plain textarea. Everything except the plain body is discarded. `handleScheduled` then clears the reply draft and the composer, so a user who was composing a formatted reply and chose "schedule" loses the reply target and all markdown with no warning. (The docs acknowledge this only for the *edit* flow, not for the initial schedule.)
### How to trigger
Reply to a message, type `**bold** @someone`, click Schedule, send. The delivered message is unformatted, unthreaded, un-mentioning plain text.
### Suggested fix
Pass the whole `IContent` through the modal (letting the textarea edit only `body`, re-deriving `formatted_body` or dropping the rich fields only when the body was edited) and preserve `m.relates_to`/`m.mentions`.
---
_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:06 -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: medium · Type: bug · Confidence: high
Location:
src/app/features/room/RoomInput.tsx:646-704(buildCurrentTextContent),:1451-1456,src/app/features/room/ScheduleMessageModal.tsx:34-36,127Problem
handleScheduleClickbuilds a fullIContent—formatted_body,m.mentions, and them.in_reply_to/thread relation from the active reply draft — but the modal only acceptsinitialBody?: stringand rebuilds{ body, msgtype: 'm.text' }from a plain textarea. Everything except the plain body is discarded.handleScheduledthen clears the reply draft and the composer, so a user who was composing a formatted reply and chose "schedule" loses the reply target and all markdown with no warning. (The docs acknowledge this only for the edit flow, not for the initial schedule.)How to trigger
Reply to a message, type
**bold** @someone, click Schedule, send. The delivered message is unformatted, unthreaded, un-mentioning plain text.Suggested fix
Pass the whole
IContentthrough the modal (letting the textarea edit onlybody, re-derivingformatted_bodyor dropping the rich fields only when the body was edited) and preservem.relates_to/m.mentions.Filed from the September 2026 client audit (branch
lotus@4bea4895).