- Shipped
- October 10, 2026 at 3:28 AM UTC
- Author
- Kamo
- Commit
- 4f90690
Labels - A label was paged through the join table by UID and each page sorted by date afterwards. UIDs only order mail within one folder and a label spans folders, so page 2 could hold mail newer than page 1. A labelled message the index had not seen was dropped after the page was cut, so pages came back short mid-label while the total (the join table's count) still counted it. - Now paged by joining the label to the search index and ordering the envelopes by date then UID, as a folder page is: one order, full pages until the last, and a total of exactly the labelled messages the index holds. The total is read off a short page for free and counted only for a full page or an empty one past the first. - MessageListIndexQueryTest compiles the new JPQL (a theta join, since the two entities share a key but no mapped association) and binds its parameters, so a mistake fails a test instead of the pod's startup. Microsoft 365 (Graph) - listMessagePage now reports a total. A short page states it; a full page reads the folder's totalItemCount, the property listFolders already selects on every mailbox. $count is deliberately not added to the listing itself: its query is parsed as a unit and the legacy Outlook REST backend has failed a whole mailbox over one unsupported part before. If the count read fails, the page still lists with its total unknown. - A page capped at Graph's $top of 200 is judged against the cap, so it is not mistaken for the last page. Shared: MessagePage.inferTotal is the one rule for "a short page is the end".