Flagged by the DB access-pattern audit (from the #148 message-open profiling) as out of scope / deferred — filing to backlog so it isn't lost.
The unified-inbox summary flows SCAN the whole messages table (verified via EXPLAIN QUERY PLAN against the exported schema, 50k rows):
observeUnifiedFolderSummaries — SCAN messages USING INDEX index_messages_timestampMillis
observeUnreadCounts — SCAN messages USING INDEX index_messages_accountId_folder_uid (COUNT; index-only)
observeFolderSummaries — SEARCH ... index_messages_accountId_folder_uid + USE TEMP B-TREE FOR ORDER BY
pagingUnifiedFolderSummaries — SCAN ... index_messages_timestampMillis (bounded by LIMIT/OFFSET)
A (folder, inInbox, timestampMillis)covering index could convert these to bounded SEARCHes and drop the temp B-tree sort.
Why deferred (do NOT do this preemptively)
Not on the message-open/tap critical path — these stay subscribed under the reader via the mailbox VM's WhileSubscribed(5000), but tapping a message does not re-run them, so they don't cause the "opening is slow" symptom.
Requires a Room migration + app/schemas export + a migration test (per CLAUDE.md) — heavier and riskier than the migration-free tap-path fixes.
The in-repo profiling notes (docs/perf/issue-124-…md) already judged these scans not hot enough to warrant it.
MessageDao.observeSummaries (the one whole-table SCAN) has no production caller — it survives only as the issue-#51 CursorWindow regression-guard test.
Revisit when
Only if profiling on a very large multi-account unified inbox shows these scans becoming hot. Then the (folder, inInbox, timestampMillis) covering index (with migration + schema export + migration test) is the lever.
Flagged by the DB access-pattern audit (from the #148 message-open profiling) as **out of scope / deferred** — filing to backlog so it isn't lost.
The unified-inbox summary flows `SCAN` the whole `messages` table (verified via `EXPLAIN QUERY PLAN` against the exported schema, 50k rows):
- `observeUnifiedFolderSummaries` — `SCAN messages USING INDEX index_messages_timestampMillis`
- `observeUnreadCounts` — `SCAN messages USING INDEX index_messages_accountId_folder_uid` (COUNT; index-only)
- `observeFolderSummaries` — `SEARCH ... index_messages_accountId_folder_uid` + `USE TEMP B-TREE FOR ORDER BY`
- `pagingUnifiedFolderSummaries` — `SCAN ... index_messages_timestampMillis` (bounded by LIMIT/OFFSET)
A `(folder, inInbox, timestampMillis)` **covering index** could convert these to bounded `SEARCH`es and drop the temp B-tree sort.
## Why deferred (do NOT do this preemptively)
- **Not on the message-open/tap critical path** — these stay subscribed under the reader via the mailbox VM's `WhileSubscribed(5000)`, but tapping a message does not re-run them, so they don't cause the "opening is slow" symptom.
- **Requires a Room migration** + `app/schemas` export + a migration test (per CLAUDE.md) — heavier and riskier than the migration-free tap-path fixes.
- The in-repo profiling notes (`docs/perf/issue-124-…md`) already judged these scans not hot enough to warrant it.
- `MessageDao.observeSummaries` (the one whole-table `SCAN`) has **no production caller** — it survives only as the issue-#51 CursorWindow regression-guard test.
## Revisit when
Only if profiling on a very large **multi-account unified inbox** shows these scans becoming hot. Then the `(folder, inInbox, timestampMillis)` covering index (with migration + schema export + migration test) is the lever.
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.
Flagged by the DB access-pattern audit (from the #148 message-open profiling) as out of scope / deferred — filing to backlog so it isn't lost.
The unified-inbox summary flows
SCANthe wholemessagestable (verified viaEXPLAIN QUERY PLANagainst the exported schema, 50k rows):observeUnifiedFolderSummaries—SCAN messages USING INDEX index_messages_timestampMillisobserveUnreadCounts—SCAN messages USING INDEX index_messages_accountId_folder_uid(COUNT; index-only)observeFolderSummaries—SEARCH ... index_messages_accountId_folder_uid+USE TEMP B-TREE FOR ORDER BYpagingUnifiedFolderSummaries—SCAN ... index_messages_timestampMillis(bounded by LIMIT/OFFSET)A
(folder, inInbox, timestampMillis)covering index could convert these to boundedSEARCHes and drop the temp B-tree sort.Why deferred (do NOT do this preemptively)
WhileSubscribed(5000), but tapping a message does not re-run them, so they don't cause the "opening is slow" symptom.app/schemasexport + a migration test (per CLAUDE.md) — heavier and riskier than the migration-free tap-path fixes.docs/perf/issue-124-…md) already judged these scans not hot enough to warrant it.MessageDao.observeSummaries(the one whole-tableSCAN) has no production caller — it survives only as the issue-#51 CursorWindow regression-guard test.Revisit when
Only if profiling on a very large multi-account unified inbox shows these scans becoming hot. Then the
(folder, inInbox, timestampMillis)covering index (with migration + schema export + migration test) is the lever.