mirror of
https://gh-proxy.org/https://github.com/klinsmaya/multica.git
synced 2026-11-11 02:46:45 +08:00
b566b5fd4e
A comment notification stores the full comment it was raised for, and both inbox lists returned it verbatim. A several-thousand-character agent reply travelled over the wire, through JSON parsing and into the client cache for every subscriber, only to be rendered as a single truncated line. The main and archived list responses now cap the body of a `new_comment` notification on an issue at 200 characters, the ellipsis included. The database keeps the full text, and `details.comment_id` is untouched. The scope is exactly the rows whose full body no client reads from the list. Opening an issue-backed notification renders the issue itself and lands on the comment through `comment_id`; everywhere else, web, desktop and mobile show that body as one line. That holds for builds already installed, so none has to change: the field, its type and the endpoints are the same. Other types keep their full body — issue-less notifications render it in the detail pane from the list cache, and Quick Create failures refill the composer from `details`. Single-item responses are unchanged. Truncation walks code points and stops at the limit, so a multi-byte character is never split and the work per row is bounded by the preview, not by the comment's length. Sampled on 264 comments from this workspace's recent issues: half exceed 200 characters (median 203, p90 3,277, max 12,251), and capping cuts their text by 86%. A list of comment notifications built from them shrinks 64% raw and 69% gzipped; an inbox's overall saving depends on its share of comment rows. Refs MUL-6967. Co-authored-by: J <[email protected]> Co-authored-by: multica-agent <[email protected]>