Origin: code review of PR #54 (drawer folder de-duplication). Cosmetic, but affects the primary Sent folder on a realistic class of accounts.
Problem
When two top-level folders share a role-derived base label, the resolver's safety net (FolderLabels.kt:54) appends the full path to both, producing a self-referential label for the real folder. The KDoc's uniqueness reasoning ("Among colliding user folders at most one is top-level (paths are unique), so the result is distinct") assumes base labels are leaf names — false when the shared base is a friendly role name (two different fullNames, one base).
Failure scenario
Server without SPECIAL-USE attributes (GreenMail; many shared hosts — Folder.kt's own KDoc concedes this is common) holding top-level Sent and Sent Items (typical after mixed-client use or an Exchange migration): both classify SENT via roleFromDisplayName, both base-label to the friendly "Sent", both are non-special and top-level (parentOf returns null), so the safety net renders "Sent [Sent]" and "Sent [Sent Items]" near the top of the drawer.
Suggested fix
Tie-break same-role folders by display name before the safety net — the folder whose displayName matches the friendly label (or the role's canonical name) keeps the clean label; others get a suffix. Also correct the KDoc: the "so the result is distinct" sketch is additionally false for same-parent-leaf grandchildren (Work/2024/Reports vs Home/2024/Reports both hit "Reports (2024)" before the net), and the final pass never re-checks rewritten labels against untouched ones, so "guaranteeing uniqueness" is slightly overclaimed.
Origin: code review of PR #54 (drawer folder de-duplication). Cosmetic, but affects the primary Sent folder on a realistic class of accounts.
## Problem
When two **top-level** folders share a **role-derived** base label, the resolver's safety net (`FolderLabels.kt:54`) appends the full path to *both*, producing a self-referential label for the real folder. The KDoc's uniqueness reasoning ("Among colliding user folders at most one is top-level (paths are unique), so the result is distinct") assumes base labels are leaf names — false when the shared base is a friendly role name (two different `fullName`s, one base).
## Failure scenario
Server without SPECIAL-USE attributes (GreenMail; many shared hosts — `Folder.kt`'s own KDoc concedes this is common) holding top-level `Sent` and `Sent Items` (typical after mixed-client use or an Exchange migration): both classify SENT via `roleFromDisplayName`, both base-label to the friendly "Sent", both are non-special and top-level (`parentOf` returns null), so the safety net renders **"Sent [Sent]"** and **"Sent [Sent Items]"** near the top of the drawer.
## Suggested fix
Tie-break same-role folders by display name before the safety net — the folder whose `displayName` matches the friendly label (or the role's canonical name) keeps the clean label; others get a suffix. Also correct the KDoc: the "so the result is distinct" sketch is additionally false for same-parent-leaf grandchildren (`Work/2024/Reports` vs `Home/2024/Reports` both hit "Reports (2024)" before the net), and the final pass never re-checks rewritten labels against untouched ones, so "guaranteeing uniqueness" is slightly overclaimed.
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.
Origin: code review of PR #54 (drawer folder de-duplication). Cosmetic, but affects the primary Sent folder on a realistic class of accounts.
Problem
When two top-level folders share a role-derived base label, the resolver's safety net (
FolderLabels.kt:54) appends the full path to both, producing a self-referential label for the real folder. The KDoc's uniqueness reasoning ("Among colliding user folders at most one is top-level (paths are unique), so the result is distinct") assumes base labels are leaf names — false when the shared base is a friendly role name (two differentfullNames, one base).Failure scenario
Server without SPECIAL-USE attributes (GreenMail; many shared hosts —
Folder.kt's own KDoc concedes this is common) holding top-levelSentandSent Items(typical after mixed-client use or an Exchange migration): both classify SENT viaroleFromDisplayName, both base-label to the friendly "Sent", both are non-special and top-level (parentOfreturns null), so the safety net renders "Sent [Sent]" and "Sent [Sent Items]" near the top of the drawer.Suggested fix
Tie-break same-role folders by display name before the safety net — the folder whose
displayNamematches the friendly label (or the role's canonical name) keeps the clean label; others get a suffix. Also correct the KDoc: the "so the result is distinct" sketch is additionally false for same-parent-leaf grandchildren (Work/2024/ReportsvsHome/2024/Reportsboth hit "Reports (2024)" before the net), and the final pass never re-checks rewritten labels against untouched ones, so "guaranteeing uniqueness" is slightly overclaimed.