Origin: code review of PR #54. Reuse/altitude cleanup — nothing breaks today; the risk is silent drift.
Problem
parentOf() (FolderLabels.kt:64) re-infers the IMAP hierarchy separator via string arithmetic (the character before the displayName suffix of fullName), relying on an unenforced cross-layer invariant: displayName == fullName.substringAfterLast(separator), established three layers away in ImapClient.listFolders (ImapClient.kt:93-96) — which reads the authoritative JavaMail folder.separator, uses it once, and discards it. The delimiter is persisted on neither FetchedFolder, FolderEntity, nor Folder.
Verified: no current input breaks the inference (displayName is only ever produced by that one derivation, and Angus Mail already modified-UTF-7-decodes LIST names). But any future change to how displayName is derived — trimming, decoding at a different layer, a second construction site — makes fullName.endsWith(displayName) false, parentOf returns null, and colliding user folders silently degrade to the [fullPath] safety-net labels. No test would fail: FolderLabelsTest's fixture helper hard-codes the identical substringAfterLast('/') derivation.
Suggested fix
Carry the separator (or a precomputed parent path) through FetchedFolder → FolderEntity → Folder and have parentOf split on it. Needs a v12→v13 column migration — add its replay to the migration-test suite from #63.
Origin: code review of PR #54. Reuse/altitude cleanup — nothing breaks today; the risk is silent drift.
## Problem
`parentOf()` (`FolderLabels.kt:64`) re-infers the IMAP hierarchy separator via string arithmetic (the character before the `displayName` suffix of `fullName`), relying on an unenforced cross-layer invariant: `displayName == fullName.substringAfterLast(separator)`, established three layers away in `ImapClient.listFolders` (`ImapClient.kt:93-96`) — which reads the authoritative JavaMail `folder.separator`, uses it once, and discards it. The delimiter is persisted on neither `FetchedFolder`, `FolderEntity`, nor `Folder`.
Verified: no current input breaks the inference (displayName is only ever produced by that one derivation, and Angus Mail already modified-UTF-7-decodes LIST names). But any future change to how `displayName` is derived — trimming, decoding at a different layer, a second construction site — makes `fullName.endsWith(displayName)` false, `parentOf` returns null, and colliding user folders silently degrade to the `[fullPath]` safety-net labels. No test would fail: `FolderLabelsTest`'s fixture helper hard-codes the identical `substringAfterLast('/')` derivation.
## Suggested fix
Carry the separator (or a precomputed parent path) through `FetchedFolder → FolderEntity → Folder` and have `parentOf` split on it. Needs a v12→v13 column migration — add its replay to the migration-test suite from #63.
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. Reuse/altitude cleanup — nothing breaks today; the risk is silent drift.
Problem
parentOf()(FolderLabels.kt:64) re-infers the IMAP hierarchy separator via string arithmetic (the character before thedisplayNamesuffix offullName), relying on an unenforced cross-layer invariant:displayName == fullName.substringAfterLast(separator), established three layers away inImapClient.listFolders(ImapClient.kt:93-96) — which reads the authoritative JavaMailfolder.separator, uses it once, and discards it. The delimiter is persisted on neitherFetchedFolder,FolderEntity, norFolder.Verified: no current input breaks the inference (displayName is only ever produced by that one derivation, and Angus Mail already modified-UTF-7-decodes LIST names). But any future change to how
displayNameis derived — trimming, decoding at a different layer, a second construction site — makesfullName.endsWith(displayName)false,parentOfreturns null, and colliding user folders silently degrade to the[fullPath]safety-net labels. No test would fail:FolderLabelsTest's fixture helper hard-codes the identicalsubstringAfterLast('/')derivation.Suggested fix
Carry the separator (or a precomputed parent path) through
FetchedFolder → FolderEntity → Folderand haveparentOfsplit on it. Needs a v12→v13 column migration — add its replay to the migration-test suite from #63.