Restoring a Secure Backup created on iOS fails on Android with foreign key violations on `message.latest_revision_id`

[june-fish]

Guidelines

• I have searched open and closed issues for duplicates
• I am submitting a bug report for existing functionality that does not work as intended
• This isn't a feature request or a discussion topic

Bug description

I've been trying to move my Signal account from an iPhone 11 to a Pixel 9 using the Signal Secure Backups paid tier. Restoring the exact same backup between iPhones works fine now, but a few months ago did not. Restoring it on Android fails every time I've tried, on both GrapheneOS and stock Pixel OS (and once in Waydroid for fun), with the current stable release (the APK from signal.org, not Google Play) and the newest pre-release from GitHub.

The restore downloads the archive, restores ~800k messages, and then fails during the "finishing" step. On the stable release this failure is completely silent -- the dialog just closes and it goes back to the "restore from a cloud backup" screen with no error. The logcat shows that the import completes, then a final integrity check throws an uncaught IllegalStateException for foreign key violations on message.latest_revision_id, and the process gets killed.

There are only a few violations out of ~800k messages. I am unsure what causes them -- Claude told me it was possibly 3 edited messages whose revision references the iOS exporter writes in a way the Android importer can't resolve -- but I haven't looked into it enough to know.

Recreating the backup from scratch on the iPhone (turn off and delete backup, re-enable, fresh backup) does not help -- the new archive fails identically, so this reproduces from the iOS exporter side, not from one stale archive.

Steps to reproduce

1. On iOS (latest App Store version), enable Signal Secure Backups (paid tier) and let a backup complete
2. On a Pixel 9 (GrapheneOS or stock, doesn't matter), install Signal, fresh install
3. During registration, choose Transfer or restore account -> From Signal Backups, enter the recovery key (or scan the QR code and choose restore from backup, the same thing happened to me for both)
4. Wait for the restore to download and process all messages

Actual result

Stable (APK from signal.org): after the message import finishes, the "finishing" dialog closes and the app silently returns to the restore-from-cloud-backup screen. logcat shows an uncaught exception and the process being killed:

07-16 14:05:15.209 E SignalUncaughtException: java.lang.IllegalStateException: Foreign key check failed! Violations: [ForeignKeyViolation(table=message, violatingRowId=392184, dependsOnTable=message, column=latest_revision_id), ForeignKeyViolation(table=message, violatingRowId=392188, dependsOnTable=message, column=latest_revision_id), ForeignKeyViolation(table=message, violatingRowId=778878, dependsOnTable=message, column=latest_revision_id), ForeignKeyViolation(table=message, violatingRowId=778881, dependsOnTable=message, column=latest_revision_id), ForeignKeyViolation(table=message, violatingRowId=802186, dependsOnTable=message, column=latest_revision_id), ForeignKeyViolation(table=message, violatingRowId=802190, dependsOnTable=message, column=latest_revision_id)]
07-16 14:05:15.209 E SignalUncaughtException:       at org.thoughtcrime.securesms.backup.v2.BackupRepository.import(BackupRepository.kt:1447)
07-16 14:05:15.209 E SignalUncaughtException:       at org.thoughtcrime.securesms.backup.v2.BackupRepository.importSignalBackup(BackupRepository.kt:1160)
07-16 14:05:15.209 E SignalUncaughtException:       at org.thoughtcrime.securesms.backup.v2.BackupRepository.restoreRemoteBackup(BackupRepository.kt:2306)
07-16 14:05:15.209 E SignalUncaughtException:       at org.thoughtcrime.securesms.backup.v2.BackupRepository.access$restoreRemoteBackup(BackupRepository.kt:188)
07-16 14:05:15.209 E SignalUncaughtException:       at org.thoughtcrime.securesms.backup.v2.BackupRepository$restoreRemoteBackup$2.invokeSuspend(BackupRepository.kt:2210)
07-16 14:05:15.209 E SignalUncaughtException:       at org.signal.registration.ui.restore.RemoteRestoreViewModel$restore$1$2.invokeSuspend(RemoteRestoreViewModel.kt:120)
07-16 14:05:15.224 I Process : Sending signal. PID: 19457 SIG: 9
07-16 14:05:15.302 I Zygote  : Process 19457 exited due to signal 9 (Killed)

While the import is running there are also repeated warnings like this, if it's relevant:

07-16 14:00:02.370 W SQLiteConnectionPool: The connection pool for database '/data/user/0/org.thoughtcrime.securesms/databases/signal.db' has been unable to grant a connection to thread 116 (JobRunner-Core-3) with flags 0x2 for 30.000002 seconds.

Newest pre-release from GitHub: same backup, same failure at the same point (around 7 minutes in, right after the message import), but the error is now caught and an error dialog is shown instead of the process crashing. The failure surfaces from RemoteBackupRestoreView / BackupRepository.importSignalBackup(BackupRepository.kt:1162). So the silent-failure part got fixed at some point, but the restore still fails.

Expected result

The restore completes. Ideally the importer would repair or drop the ~6 orphaned latest_revision_id references (or the iOS exporter wouldn't emit them) rather than discarding an entire 800k-message restore over them. iOS -> Android restores are documented as supported, so this backup should be importable.

Screenshots

No response

Device

Pixel 9 and iPhone 11

Android version

17 (Stock OS & GrapheneOS -- attached logs are from stock)

Signal version

8.19.2

Link to debug log

Full logcat captures from both builds are attached (stable-apk-logcat.txt and prerelease-apk-logcat.txt). Lines containing my home Wi-Fi network's SSID/BSSID/IP have been removed for privacy; nothing Signal-related was removed. Let me know if there's any other logs I should provide too.

stable-apk-logcat.txt
prerelease-apk-logcat.txt

[june-fish]

Update: I had Claude find the root cause, and confirmed a fix it wrote on-device. The same iOS backup that aborted every time now restores fully.

Root cause

iOS and Android store edited messages differently in their local databases, and the shared backup format (libsignal's ChatItem + revisions[]) encodes neither model's invariants. An archive that is valid under iOS's rules can therefore violate Android's, and the import aborts at the end. This is a storage-model divergence, not a format-parsing problem: both platforms read the same wire format, which is why the restore reaches "finishing" before failing.

The divergence:

• iOS keeps edit history in a separate EditRecord table, built from real, already-inserted row ids (latestRevisionId: latestRevisionMessage.sqliteRowId!). Interactions are keyed by a uniqueId UUID, with no (timestamp, author, thread) uniqueness, so two messages sharing a send-time coexist. The archive round-trips cleanly iOS to iOS.
• Android stores edit history as self-referential FK columns in the message table (ON DELETE CASCADE), wired from predicted ids, and enforces UNIQUE(date_sent, from_recipient_id, thread_id).

Why it aborts on Android

Importing an iOS-legal archive runs into Android's uniqueness invariant:

1. The archive can contain a row whose (date_sent, from_recipient_id, thread_id, body) duplicates an edited message's latest-revision row (legal on iOS, not on Android).
2. FKs are disabled during import. removeDuplicatesPostBackupRestore() deletes the duplicate, which can be that latest-revision row. With FKs off, ON DELETE CASCADE does not fire, so its past revisions are left pointing at a latest_revision_id that no longer exists.
3. The final PRAGMA foreign_key_check reports the orphans and rolls back the whole restore.

That routine already repairs orphaned original_message_id references, but has no equivalent for latest_revision_id. My crash was exactly that: 6 violations on latest_revision_id, 2 per edited message (3 edited messages).

java.lang.IllegalStateException: Foreign key check failed! Violations: [
  ForeignKeyViolation(table=message, violatingRowId=392184, dependsOnTable=message, column=latest_revision_id),
  ... x6 ]
  at org.thoughtcrime.securesms.backup.v2.BackupRepository.import(BackupRepository.kt)

The orphan mechanism is confirmed (the fix below restored my backup on-device). That the colliding row originates from iOS's lack of uniqueness is the best-supported explanation, but not something I could be sure of from the archive itself.

Steps to reproduce

1. On iOS, edit a message or two.
2. Make a Signal backup.
3. Restore it on Android.

Suggested fix

Mirror the existing orphan cleanup for latest_revision_id, in removeDuplicatesPostBackupRestore() just before the original_message_id cleanup. I detach the orphans rather than delete them, so no message text is lost (worst case, a pre-edit version shows as a standalone message):

writableDatabase.execSQL(
  """
  UPDATE $TABLE_NAME
  SET $LATEST_REVISION_ID = NULL, $ORIGINAL_MESSAGE_ID = NULL, $REVISION_NUMBER = 0
  WHERE $LATEST_REVISION_ID IS NOT NULL AND $LATEST_REVISION_ID NOT IN (SELECT $ID FROM $TABLE_NAME)
  """
)

A one-line DELETE, symmetric with the existing original_message_id cleanup, would also stop the crash but would drop the edit history.

On-device confirmation

Built current main with only that change on a Pixel 9. The backup that previously aborted every time now completes:

[import] Remove duplicate messages...
[import] Re-enabling foreign keys...
[import] Finished! ... [chatItem] count: 790814

No FK violations, no crash, and the app opens with full history. Happy to open a PR with a regression test if useful, but I did use Claude to fix this issue and I could not find Signal's policy on AI contributions anywhere.

[cody-signal]

Thanks, we actually put a fix in for this already last week, it'll come out in 8.21