I thought sqlite was very resilient and have a hard time understanding how an sqlite file can be corrupted. Are they manipulating the sqlite file outside of sqlite APIs? Are they mixing up file descriptors and writing garbage into an sqlite handle?

Not sure how reliable and resilient SQLCipher is but that might (significantly?) increase the risk for a bug/corruption to occur. And the encryption certainly makes the analysis more difficult (while, at least on GNU/Linux, I don't see any advantage as the encryption key is stored unencrypted in ~/.config/Signal/config.json - not sure if other Desktop platforms support secure keystores like on Android and iOS). I briefly tried to analyze my corrupted DB but quickly gave up as I'm not familiar with SQLCipher and basically only got a generic "Error: file is not a database" error message when trying to decrypt it (and there's no plaintext header IIRC so it looks just like random data).

I also had multiple backups of the SQLCipher DB that I could successfully access manually but I was unable to use them for Signal-Desktop (not sure if this was due to some other Electron DBs/state, the stateful Signal protocol, or something else - IIRC the only hint was the "Database startup error: Error: SQLITE_NOTADB: file is not a database" message that didn't really help much).