https://bugs.kde.org/show_bug.cgi?id=525069
Bug ID: 525069
Summary: Server-side subscriptions cause duplicate INBOX
collections (UNIQUE constraint failure on
CollectionTable), breaking folder synchronisation
Classification: Frameworks and Libraries
Product: Akonadi
Version First 6.0.0
Reported In:
Platform: Ubuntu
OS: Linux
Status: REPORTED
Severity: major
Priority: NOR
Component: IMAP resource
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
## Summary
When server-side subscriptions are enabled on an IMAP account, the IMAP
resource
tries to create the INBOX collection a second time under a different remote ID,
the insertion is rejected by the database with a UNIQUE constraint violation on
`CollectionTable(parentId, name)`, and the account's collection tree is left in
a broken state. Everything downstream of that failure misbehaves: folders sync
partially or not at all, synchronisation stalls, folder and account names are
shown incorrectly, some accounts do not appear at all, and messages
occasionally
end up displayed under the wrong folder.
Disabling server-side subscriptions — with no other configuration change, same
accounts, same servers, same folders — makes the problem disappear completely.
Synchronisation then works reliably and is noticeably more responsive.
I have been hit by this, in varying degrees of severity, for years across
several KDE PIM releases. Only recently did I isolate server-side subscriptions
as the trigger.
## Steps to reproduce
1. Configure an IMAP account in Kontact/KMail.
2. Open the account settings, go to the Advanced tab, tick
*Enable server-side subscriptions*, and select the subscribed folders.
3. Restart Akonadi (`akonadictl restart`) and trigger a full synchronisation.
4. Watch `akonadi_imap_resource` in the Akonadi log (see below).
## Observed result
The log shows the resource attempting to insert a collection named `INBOX`
whose remote ID carries a leading hierarchy separator, while a collection named
`INBOX` already exists under the same parent:
```
org.kde.pim.akonadiserver: DATABASE ERROR:
org.kde.pim.akonadiserver: Error code: "2067"
org.kde.pim.akonadiserver: DB error: "UNIQUE constraint failed:
CollectionTable.parentId, CollectionTable.name"
org.kde.pim.akonadiserver: Values: QList(QVariant(QString, "/INBOX"),
QVariant(QString, ""), QVariant(QString, "INBOX"), QVariant(qlonglong, 424),
QVariant(qlonglong, 7), ...)
org.kde.pim.akonadiserver: Error during insertion into table "CollectionTable"
"UNIQUE constraint failed: CollectionTable.parentId, CollectionTable.name"
org.kde.pim.akonadiserver: Failed to append Collection "INBOX" in resource
"akonadi_imap_resource_0"
org.kde.pim.akonadiserver: Error while handling command CreateCollection on
connection akonadi_imap_resource_0
```
The same failure occurs on a second, unrelated IMAP account, where the remote
ID
uses a different hierarchy separator:
```
org.kde.pim.akonadiserver: Values: QList(QVariant(QString, ".INBOX"),
QVariant(QString, ""), QVariant(QString, "INBOX"), QVariant(qlonglong, 434),
QVariant(qlonglong, 48), ...)
org.kde.pim.akonadiserver: Failed to append Collection "INBOX" in resource
"akonadi_imap_resource_47"
org.kde.pim.akonadiserver: Error while handling command CreateCollection on
connection akonadi_imap_resource_47
```
Immediately afterwards the resource can no longer resolve its own collection
hierarchy, and IDLE setup fails:
```
org.kde.pim.akonadiserver: Handler exception when handling command
FetchCollections on connection akonadi_imap_resource_47 : Hierarchical RID does
not specify an existing collection
org.kde.pim.imapresource: CollectionFetch for idling failed. error= 103 ,
errorString= "Hierarchical RID does not specify an existing collection"
```
User-visible consequences:
- Synchronisation is dramatically slower than with the option disabled.
- Some folders never finish syncing; others are only partially populated
(message counts in KMail do not match the counts on the server).
- After some progress the resource stops advancing and stays that way
indefinitely — no error dialog, no timeout, no recovery. Triggering
*Check mail* again makes it run briefly and then stall in the same way.
- Several account names are displayed incorrectly.
- Some accounts do not appear in the folder tree at all.
- Occasionally, messages belonging to one folder are shown inside a different
folder.
- Akonadi crashes / resources are restarted repeatedly during this process.
## Expected result
Server-side subscriptions should restrict synchronisation to the subscribed
subset of folders. Each mailbox should map to exactly one collection regardless
of whether its name is discovered through `LIST` or through the subscription
list, and the operation should be at least as fast and as reliable as syncing
every folder, since strictly less work is being done.
## Analysis / hypothesis
The two failing inserts use remote IDs `/INBOX` and `.INBOX` — the same mailbox
name prefixed with the server's hierarchy separator — while a collection with
name `INBOX` already exists under the same parent. This looks like the
subscription code path building the remote ID differently from the folder
listing code path: the personal namespace prefix (empty on both these servers)
is concatenated with the separator, producing `<separator>INBOX` instead of
`INBOX`.
Because the remote ID differs, the resource treats it as a new collection and
asks the server to create it; because the *name* is identical and the parent is
the same, the database rejects it. The resource then holds a remote ID that
does
not correspond to any stored collection, which is exactly what the subsequent
`FetchCollections` failure reports. Every later operation that resolves a
collection by hierarchical remote ID is then unreliable, which would explain
the
wrong names, missing accounts, and misplaced messages.
The `.INBOX` case comes from a Dovecot server whose personal namespace is
`(("INBOX." "."))`. In that layout `INBOX` itself is a mailbox at the root of
the namespace, not below the `INBOX.` prefix. The observed remote ID `.INBOX`
is
exactly what you get from composing `parentRemoteId + separator + mailboxName`
when the parent is the account root and its remote ID is empty. The other
account, whose separator is `/`, produced `/INBOX` — the same composition with
a
different separator.
This is consistent across both servers and suggests the defect is not
server-specific and not namespace-prefix-specific: it looks like a missing
empty-parent check when the subscription code path builds the remote ID for a
top-level mailbox. The `LIST`-based path evidently gets it right, since a
collection named `INBOX` already exists by the time the failing insert happens.
Note that this reproduces against two different IMAP servers using two
different
hierarchy separators, so it does not look server-specific.
**Possibly related:** bug 375244 ("Akonadi IMAP Resource should handle
'Duplicate entry in CollectionTable' errors") describes the same downstream
consequence — the resource silently stops syncing folder-tree changes and
messages in the affected folder after a duplicate-collection insert — but does
not identify a trigger. This report adds a reproducible trigger (server-side
subscriptions) and a probable cause for the duplicate.
## Workaround
Unticking *Enable server-side subscriptions* on every account. Nothing else was
changed. All the symptoms above stopped immediately and have not returned.
## Software / OS versions
- Operating system: Kubuntu 26.04
- KDE Plasma: 6.6.6
- KDE Frameworks: 6.24.0
- Qt: 6.10.2
- kdepim-runtime (IMAP resource): [FILL IN]
- akonadi-server: 25.12.3
- KMail: 6.6.3
- Akonadi database backend: SQLite (error code 2067 is
SQLITE_CONSTRAINT_UNIQUE)
## Additional information
**IMAP servers involved:** the affected mailboxes are hosted by Aruba
(`imaps.aruba.it`, port 993, implicit TLS). The server is Dovecot; the version
is not advertised. Pre-login greeting and capabilities:
```
* CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+
AUTH=PLAIN
a OK Pre-login capabilities listed, post-login capabilities have more.
```
Post-login capabilities:
```
IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY
THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL
CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1
CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS
BINARY MOVE SNIPPET=FUZZY XLIST SPECIAL-USE QUOTA ACL RIGHTS=texk
```
NAMESPACE response:
```
* NAMESPACE (("INBOX." ".")) NIL NIL
```
So the server does advertise NAMESPACE, LIST-EXTENDED, CHILDREN and
SPECIAL-USE,
and declares a single personal namespace with prefix `INBOX.` and separator
`.`.
A second IMAP account, on a different server whose hierarchy separator is `/`,
fails in exactly the same way (`/INBOX`, see the log above). Its provider is
not
detailed here, but the identical failure across two independent IMAP
implementations is what suggests the defect is client-side.
- Hierarchy separators seen in the failing remote IDs: `/` and `.`
- Number of IMAP accounts configured: 35
**Unrelated noise in the attached log:** the `org.kde.kgapi` /
`org.kde.pim.google` "Access token has expired or is invalid" lines come from
separate Google Calendar/Contacts/Tasks resources and are not part of this
report. The same applies to any `akonadi_html_to_text` aborts, which appear to
be bug 516865 (html2text panic on empty input, from the Debian/Ubuntu packaging
of akonadi-search — Debian #1142303, Ubuntu LP #2162370).
--
You are receiving this mail because:
You are watching all bug changes.
