Summary
When a user account is re-synced (e.g., via HandleRefreshEvent), Bridge creates new Gluon user IDs and databases, but the old databases and message store directories are never deleted. The deferred deletion mechanism (DeleteDB → DeleteDeferredDBFiles) appears to have a gap where old data persists indefinitely.
Observed behavior
On a real user system running Bridge v3.22.0 (br-216), the gluon/backend/ directory contains:
| Gluon ID |
Messages |
DB size |
Store size |
Last message date |
Status |
411e5a51 |
86,789 |
167 MB |
3.6 GB (65,535 files) |
July 2025 |
Orphaned — loaded at startup but stale |
22ba26c1 |
7,083 |
14 MB |
236 MB |
Dec 2024 |
Orphaned |
a7ff329c |
64,785 |
128 MB |
3.2 GB |
Today |
Active |
411e and a7ff have the exact same mailbox structure (12 identical mailboxes) but zero message overlap — confirmed by cross-checking remote_id values. They are clearly the same Proton account before and after a re-sync.411e is still referenced at startup: "Loading existing IMAP user" gluonID="411e5a51-..." and receives "Received mailbox message count" events. It also receives MailboxCreated updates during reconnection.- 3.8 GB of disk space is wasted on orphaned data.
Root cause analysis
The re-sync flow in imapservice/service.go calls removeConnectorsFromServer(ctx, s.connectors, true) with deleteData=true, which should trigger RemoveIMAPUser → DeleteDB. However, DeleteDB uses deferred deletion (renaming files for later cleanup via DeleteDeferredDBFiles). If the deferred cleanup never runs (crash, interrupted startup, or a code path that skips it), the old databases remain permanently.
Expected behavior
After a re-sync completes and the new Gluon user ID is created, the old database and its corresponding store/ directory should be fully deleted — either immediately or reliably on the next startup.
Impact
- Disk usage grows unboundedly with each re-sync
- Orphaned databases are loaded at startup, consuming memory and generating unnecessary log events
- The orphaned
store/ directory can hit filesystem limits (65,535 files in a single directory on macOS)
Summary
When a user account is re-synced (e.g., via
HandleRefreshEvent), Bridge creates new Gluon user IDs and databases, but the old databases and message store directories are never deleted. The deferred deletion mechanism (DeleteDB→DeleteDeferredDBFiles) appears to have a gap where old data persists indefinitely.Observed behavior
On a real user system running Bridge v3.22.0 (br-216), the
gluon/backend/directory contains:411e5a5122ba26c1a7ff329c411eanda7ffhave the exact same mailbox structure (12 identical mailboxes) but zero message overlap — confirmed by cross-checkingremote_idvalues. They are clearly the same Proton account before and after a re-sync.411eis still referenced at startup:"Loading existing IMAP user" gluonID="411e5a51-..."and receives"Received mailbox message count"events. It also receivesMailboxCreatedupdates during reconnection.Root cause analysis
The re-sync flow in
imapservice/service.gocallsremoveConnectorsFromServer(ctx, s.connectors, true)withdeleteData=true, which should triggerRemoveIMAPUser→DeleteDB. However,DeleteDBuses deferred deletion (renaming files for later cleanup viaDeleteDeferredDBFiles). If the deferred cleanup never runs (crash, interrupted startup, or a code path that skips it), the old databases remain permanently.Expected behavior
After a re-sync completes and the new Gluon user ID is created, the old database and its corresponding
store/directory should be fully deleted — either immediately or reliably on the next startup.Impact
store/directory can hit filesystem limits (65,535 files in a single directory on macOS)