fix: text rendering without line breaks when `MESSAGE_MAX_PARSE_LENGTH` environment variable is exceeded

Merged
NA
2mo ago
+206-22

Proposed changes (including videos or screenshots)

Line breaks are not characters a renderer prints, they are structures the parser produces:
message-parser emits one PARAGRAPH per line and a LINE_BREAK per blank line, and marked
(with breaks: true) turns each one into a <br>. Any \n left inside a text node is collapsed
into a single space by HTML.

So every path that skips parsing and renders the raw text loses the line breaks. That happens
whenever a message has no md: messages longer than MESSAGE_MAX_PARSE_LENGTH, which the server
stores without it, and messages that are never parsed server-side, such as E2EE ones. Before the
parser limit existed these fallbacks were rarely reached, which is why the problem only surfaced now.

Proposed solution

toPlainTextRoot (new): maps text to the same block structure the parser would produce,
one paragraph per line, a line break per blank line, without interpreting any markup. Line endings
are normalized and a trailing newline does not add an empty line. Covered by unit tests, including
a parity check against the parser itself for text that carries no syntax.

Message rendering: the fallbacks now go through that helper instead of rendering a raw string,
so unparsed messages keep the same shape as parsed ones:

  • parseMessageTextToAstMarkdown and normalizeThreadMessage: channel and thread messages,
    Threads and Discussions contextual bars

  • useMessageBody: parent message preview above a thread reply, text in blue color:

    image
  • ContextMessage: moderation console (Manage -> Workspace -> Moderation)

    image
  • ContactHistoryMessage: Omnichannel contact history conversation

  • QuoteAttachment: quotes, pin and forward modals, composer quote preview

  • ReportMessageModal: message preview

MarkdownText: the document variant parses with breaks: true, so its unparsed fallback now
keeps the line breaks too. This covers attachment text rendered by DefaultAttachment (pinned
messages and app/integration attachments), file descriptions on screens that do not normalize
attachments, and the canned response and outbound template previews. The inline and
inlineWithoutBreaks variants keep collapsing line breaks on purpose (room topic, user status,
announcements, directory rows), and truncated text is left untouched.

Issue(s)

CORE-2490 [Regression] Multiline messages above MESSAGE_MAX_PARSE_LENGTH render as a single paragraph

Steps to test or reproduce

Steps to test or reproduce

  1. Setup: Run Rocket.Chat with MESSAGE_MAX_PARSE_LENGTH=10.

  2. Send a multi-line message that exceeds the limit, for example:

       line one **not bold**
       line two

       line four after a blank line

Note: only messages sent after the server restart are stored without md. Older
messages keep the md they were saved with and will not exercise this path.

  1. Places to check. In all of them the line breaks must be preserved, blank lines must
    stay blank, and the markdown syntax must remain literal:
    • Message in a channel
    • Message inside a thread
    • Threads contextual bar (kebab → Threads): list item preview
    • Discussions contextual bar (kebab → Discussions): list item preview
    • Parent message preview shown above a thread reply in the main list. Expected here is
      only the first line, matching how short messages already render
    • Report message modal (kebab → Report): message preview
    • Admin → Moderation → reported message
    • Omnichannel → Contact Center → contact → History → conversation messages
    • Message edited to cross the limit (starts under it, ends over it)
    • Message in an E2EE room, which is never parsed server-side
    • Auto-translated message, if a translation service is configured
    • Quote a multi-line message: the quote must show every line, including the first one.
    • Pin message modal: multi-line message preview (kebab → Pin)
    • Forward message modal: multi-line message preview
    • Thread reply shown in the main channel list: a multi-line reply over the limit must show only its
      first line, not every line concatenated

Further comments

Summary by CodeRabbit

Bug Fixes

  • Improved display of long and plain-text messages while preserving line breaks and blank lines.
  • Standardized message rendering across quoted attachments, moderation views, contact history, thread previews, and report dialogs.
  • Improved handling of different line-ending formats and trailing breaks.
  • Preserved mentions, emojis, and markdown syntax as visible text when full formatting is unavailable.

Tests

  • Added coverage for plain-text conversion, multiline content, and line-break behavior.