From 0bff5cd5c3e3c8d833d251e76471ef0e9b576f5e Mon Sep 17 00:00:00 2001 From: atlas Date: Wed, 3 Jun 2026 12:58:22 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20address=20argus=20nits=20=E2=80=94=20la?= =?UTF-8?q?tency=20note=20in=20collect=5Funread,=20unread=5Fcount=20retent?= =?UTF-8?q?ion=20rationale?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- hive-matrix-mcp/src/handlers.rs | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/hive-matrix-mcp/src/handlers.rs b/hive-matrix-mcp/src/handlers.rs index e2b9e8a2..89742d1f 100644 --- a/hive-matrix-mcp/src/handlers.rs +++ b/hive-matrix-mcp/src/handlers.rs @@ -346,9 +346,13 @@ pub async fn read_room(client: &Client, room_ref: &str, limit: Option) -> /// Return the number of joined rooms with at least one unread /// notification according to the server-side push notification counts -/// cached by the matrix-sdk client. Used by the harness to surface -/// unread matrix activity in `get_loose_ends` without exposing -/// message content. +/// cached by the matrix-sdk client. +/// +/// The harness uses [`unread_summary`] (richer, with per-room body +/// snippets) rather than this endpoint. `unread_count` is kept as a +/// lightweight public endpoint for callers that only need the count +/// and want to avoid the `/messages` network round-trips that +/// [`collect_unread`] issues for count==1 rooms. #[must_use] pub fn unread_count(client: &Client) -> DaemonResponse { let rooms = client @@ -364,6 +368,13 @@ pub fn unread_count(client: &Client) -> DaemonResponse { /// one unread notification the last message body is fetched via the /// `/messages` endpoint (best-effort; failures leave `last_body` as /// `None`). Rooms with zero unreads are omitted. +/// +/// **Latency note**: each count==1 room triggers a live `/messages` +/// network request to the matrix homeserver to retrieve the message +/// body. This adds per-room round-trip latency to `get_loose_ends` +/// and the wake-signal path. Acceptable in practice (rooms with +/// unread are few; request is best-effort), but worth bearing in +/// mind if latency becomes a concern. #[must_use] pub async fn collect_unread(client: &Client) -> Vec { use crate::protocol::RoomUnread;