Issue Description
I went to upgrade from 0.16.17 to 0.16.18 and noted in the logs that I am getting data corruption for my CardDAV.
Yesterday I decided to redo my entire address book, so I logged into the Stalwart webui as my user, deleted all address books, and then created a new one. From here I just went through yesterday and today and re-created all of my contacts from my Phone. They all seemed to sync and display okay. However, while I can see all of my contacts on my phone still when I check with any other client the server shows nothing.
If I login to the webui and look at my user’s address books now the list is empty and nothing is there. I also cannot create any new address book at this time.
The log file shows…
2026-08-17T23:05:31Z ERROR Data corruption detected (store.data-corruption) listenerId = “https”, localPort = 443, remoteIp = , remotePort = 59441, details = “Archive integrity compromised”, value = base64:, causedBy = “crates/store/src/write/serialize.rs:72”, causedBy = “crates/store/src/dispatch/store.rs:99”, causedBy = “crates/common/src/storage/archive.rs:60”, accountId = 10, collection = 11, causedBy = “crates/groupware/src/cache/calcard.rs:164”, causedBy = “crates/dav/src/common/propfind.rs:1632”, causedBy = “crates/dav/src/common/propfind.rs:1179”, url = “/dav/card//”, type = “CardDAV”, elapsed = 3ms
Expected Behavior
No errors and address book works
Actual Behavior
There’s an error and the address book will not populate nor allow me to create new ones
Reproduction Steps
- Delete all address books
- Start re-creating all of your contacts on your phone
- At some point it fails
Stalwart Version
v0.16.x
Installation Method
Binary (Linux)
Database Backend
FoundationDB
Blob Storage
S3-compatible
Search Engine
Elasticsearch
Directory Backend
Internal
I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
on
The good news is that there is no actual data corruption, this is an FDB layer bug (present since the beginning of time, unrelated to v0.16.18) in which storing a large value in chunks and then updating that value with a smaller one left orphaned chunks that when re-assembled could not be deserialized. This has been fixed in v0.16.19 which will be released next week.
The bad news is that you have some orphaned chunks in your database, but these can be fixed running this script. The script won’t delete anything unless you run it with the --commit parameter, so you can try it out first before deleting any records. If you are unsure, see any errors, or too many orphaned records that you don’t feel confident deleting, post the script output here and we’ll look into it.
Thanks. This was perfect. I ran the script and it found two orphaned chunks. Both were deleted successfully.
One thing of note is that when running it with --commit, only then does it say “Stalwart must be stopped” but since you’re running the script it’s too late and already does its thing.
I restarted Stalwart afterwards just to be safe.
I can now see additional address books and there are no more errors in the logs. Everything looks good.
Thanks, again!
# python repair_fdb_chunks.py
DRY RUN. No key will be deleted. Pass --commit to apply the repair.
Scanning subspace 'd' (directory)...
Scanning subspace 'e' (queue message)...
Scanning subspace 'f' (task queue)...
Scanning subspace 'h' (outbound reports)...
Scanning subspace 'j' (deleted items)...
Scanning subspace 'o' (telemetry spans)...
Scanning subspace 'p' (property)...
Scanning subspace 'r' (inbound reports)...
Scanning subspace 's' (registry)...
Scanning subspace 'w' (spam samples)...
Records scanned: 29776
Orphaned chunks: 2
Re-run with --commit to delete them.
# python repair_fdb_chunks.py --commit
COMMIT MODE. Orphaned chunks will be deleted. Stalwart must be stopped.
Scanning subspace 'd' (directory)...
Scanning subspace 'e' (queue message)...
Scanning subspace 'f' (task queue)...
Scanning subspace 'h' (outbound reports)...
Scanning subspace 'j' (deleted items)...
Scanning subspace 'o' (telemetry spans)...
Scanning subspace 'p' (property)...
Scanning subspace 'r' (inbound reports)...
Scanning subspace 's' (registry)...
Scanning subspace 'w' (spam samples)...
Records scanned: 29776
Orphaned chunks: 2
Chunks deleted: 2