Phase-3 review finding (MEDIUM/correctness+security). AccountRepositoryImpl.deleteAccount (:74) removes the account row, credential, channel, message rows, folders, and backfill progress — but NOT the on-disk attachment files. Those are written by MailRepositoryImpl.ensureAttachmentFile to attachmentCacheDir(cacheDir, messageId) keyed by message id; the only cleanup paths iterate still-existing accounts. Once the account + its message rows are gone, nothing can enumerate those message ids again → every downloaded/prefetched attachment for the deleted account stays as a plaintext file in cacheDir indefinitely. Drafts + their persistable URI grants are also never released. A user deleting an account to remove their data leaves sensitive attachments behind. Fix: in deleteAccount, before deleting message rows, collect the account's message ids and deleteRecursively() each attachment dir; release the account's draft URI grants (AttachmentUriGrants). Test.
Phase-3 review finding (MEDIUM/correctness+security). `AccountRepositoryImpl.deleteAccount` (:74) removes the account row, credential, channel, message rows, folders, and backfill progress — but NOT the on-disk attachment files. Those are written by `MailRepositoryImpl.ensureAttachmentFile` to `attachmentCacheDir(cacheDir, messageId)` keyed by message id; the only cleanup paths iterate still-existing accounts. Once the account + its message rows are gone, nothing can enumerate those message ids again → every downloaded/prefetched attachment for the deleted account stays as a **plaintext file in cacheDir indefinitely**. Drafts + their persistable URI grants are also never released. A user deleting an account to remove their data leaves sensitive attachments behind. **Fix:** in `deleteAccount`, before deleting message rows, collect the account's message ids and `deleteRecursively()` each attachment dir; release the account's draft URI grants (`AttachmentUriGrants`). Test.
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.
Phase-3 review finding (MEDIUM/correctness+security).
AccountRepositoryImpl.deleteAccount(:74) removes the account row, credential, channel, message rows, folders, and backfill progress — but NOT the on-disk attachment files. Those are written byMailRepositoryImpl.ensureAttachmentFiletoattachmentCacheDir(cacheDir, messageId)keyed by message id; the only cleanup paths iterate still-existing accounts. Once the account + its message rows are gone, nothing can enumerate those message ids again → every downloaded/prefetched attachment for the deleted account stays as a plaintext file in cacheDir indefinitely. Drafts + their persistable URI grants are also never released. A user deleting an account to remove their data leaves sensitive attachments behind. Fix: indeleteAccount, before deleting message rows, collect the account's message ids anddeleteRecursively()each attachment dir; release the account's draft URI grants (AttachmentUriGrants). Test.