getNotificationType is called synchronously inside the RoomEvent.Timeline handler for every single live timeline event in every room (via mx.getRoomPushRule + a full linear scan of pushRules.global.override when no room-kind rule exists, findMutedRule). In a very active server/account with many muted rooms and a bursty sync (catch-up after reconnect), this results in an O(events × override-rules) rescan with no caching, all synchronously on the event-emission microtask. Not correctness-affecting, but a case of "heavy per-event work" the brief calls out explicitly.
How to trigger
Reconnect after being offline in an account with many rooms/override rules and receive a backlog of timeline events across many rooms at once.
Suggested fix
Memoize getNotificationType per (pushRulesEventId, roomId) (it already only changes when the m.push_rules account-data event updates), invalidating the cache when AccountDataEvent.PushRules changes instead of recomputing per event.
Filed from the September 2026 client audit (branch lotus @ 4bea4895).
**Severity:** low · **Type:** performance · **Confidence:** medium
**Location:** `src/app/utils/room.ts:191-209`, `src/app/pages/client/ClientNonUIFeatures.tsx:598-617`
### Problem
`getNotificationType` is called synchronously inside the `RoomEvent.Timeline` handler for every single live timeline event in every room (via `mx.getRoomPushRule` + a full linear scan of `pushRules.global.override` when no room-kind rule exists, `findMutedRule`). In a very active server/account with many muted rooms and a bursty sync (catch-up after reconnect), this results in an O(events × override-rules) rescan with no caching, all synchronously on the event-emission microtask. Not correctness-affecting, but a case of "heavy per-event work" the brief calls out explicitly.
### How to trigger
Reconnect after being offline in an account with many rooms/override rules and receive a backlog of timeline events across many rooms at once.
### Suggested fix
Memoize `getNotificationType` per `(pushRulesEventId, roomId)` (it already only changes when the `m.push_rules` account-data event updates), invalidating the cache when `AccountDataEvent.PushRules` changes instead of recomputing per event.
---
_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:29 -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: performance · Confidence: medium
Location:
src/app/utils/room.ts:191-209,src/app/pages/client/ClientNonUIFeatures.tsx:598-617Problem
getNotificationTypeis called synchronously inside theRoomEvent.Timelinehandler for every single live timeline event in every room (viamx.getRoomPushRule+ a full linear scan ofpushRules.global.overridewhen no room-kind rule exists,findMutedRule). In a very active server/account with many muted rooms and a bursty sync (catch-up after reconnect), this results in an O(events × override-rules) rescan with no caching, all synchronously on the event-emission microtask. Not correctness-affecting, but a case of "heavy per-event work" the brief calls out explicitly.How to trigger
Reconnect after being offline in an account with many rooms/override rules and receive a backlog of timeline events across many rooms at once.
Suggested fix
Memoize
getNotificationTypeper(pushRulesEventId, roomId)(it already only changes when them.push_rulesaccount-data event updates), invalidating the cache whenAccountDataEvent.PushRuleschanges instead of recomputing per event.Filed from the September 2026 client audit (branch
lotus@4bea4895).