- Shipped
- August 27, 2026 at 3:25 PM UTC
- Author
- Kamo
- Commit
- f66aad7
Every listing for Mike@OptionOne.com returned 400 RequestBroker--ParseUri ("Could not find a property named 'size' on type **************** and the mailbox was unusable. The request goes to /v1.0, but the error names the legacy Outlook REST type, not microsoft.graph.message: for a tenant whose mailbox still resolves to the legacy backend, Graph answers with a Message that does not declare 'size'. $select is parsed as a unit, so one unsupported name fails the whole request instead of dropping a column -- the entire inbox, not a number on a row. Drop 'size' from MSG_SELECT, which covers all three message paths that share it (listMessages, getMessage, search). Requesting it only on the single-message path would just move the same 400 from "inbox won't load" to "message won't open", since the legacy type lacks it everywhere. Nothing depends on the value: organization storage accounting is measured independently over IMAP by MailboxStorageMeasurer, and EmailMessage already documents sizeBytes == 0 as "the provider did not report one", so the absent property degrades through longOf() to exactly that sentinel. The mapping keeps reading 'size' so a Graph-native response is still sized. Attachments are a different type that genuinely has 'size'; their separate select is untouched. No per-tenant capability flag and no retry-without-size: a listing that silently retries would hide the next such breakage. Tests pin that no message select asks for 'size' on any of the three paths, that the other fourteen properties survive, that a missing size resolves to zero, and that attachment size is still requested and parsed. Verified non-vacuous -- restoring the old constant fails all three select tests.