Greptile Summary

This PR improves cold-start performance by prioritizing restoration of saved-contact identities before the full peer-identity bulk restore, and deferring the bulk restore by 5 seconds to reduce launch contention. The approach is sound and the measured improvement (~16-18 s → ~5 s splash) validates the change. The refactored restorePeerIdentitiesInBatches loop is cleaner than the original and the alreadyRestoredIdentityHashes deduplication is correct (both sides use the same Reticulum identity hash format: first 16 bytes of SHA-256 of public key).

Key findings:

• restoreContactIdentities bypasses the 500-item OOM batch limit — all contacts are sent to restorePeerIdentities in a single IPC call, which is the same pattern the bulk restore deliberately avoided. Users with a large contacts list could see the same memory spike on the contact restore step.
• totalRestored under-counts when all batch entries are filtered — the final log message will be inaccurate any time an entire raw batch is skipped due to deduplication, making it harder to verify restoration completeness during debugging.
• The new getRestorableContactsForIdentity DAO query and getRestorableContactIdentitiesForActiveIdentity repository method are well-structured; the priority ordering (relay → pinned → lastInteraction → added) matches the PR intent.

Confidence Score: 3/5

• The PR improves startup performance but introduces a potential OOM regression for users with large contact lists; functional correctness is otherwise preserved.
• The core sequencing and deduplication logic is correct. However, restoreContactIdentities sends all contacts in a single unbatched IPC call — directly at odds with the 500-item OOM guard that already exists in restorePeerIdentitiesInBatches. For typical users (< 100 contacts) this is fine, but for power users or imported address books the risk is real. The logging inaccuracy when batches are fully filtered is a lesser concern but still worth fixing before merge.
• app/src/main/java/com/lxmf/messenger/ColumbaApplication.kt — specifically the restoreContactIdentities function.

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant App as ColumbaApplication
    participant CR as ContactRepository
    participant SP as ServiceReticulumProtocol
    participant Conv as ConversationRepository

    App->>App: restorePeerIdentities()
    App->>App: launch(Dispatchers.IO)

    Note over App: Step 1 – Priority contacts
    App->>CR: getRestorableContactIdentitiesForActiveIdentity()
    CR-->>App: List<Pair<identityHash, publicKey>>
    App->>SP: restorePeerIdentities(all contacts in ONE call)
    SP-->>App: Result<Int> (count restored)
    App->>App: build restoredContactIdentityHashes set (if success)

    Note over App: 5-second delay
    App->>App: delay(5000 ms)

    Note over App: Step 2 – Bulk batched restore
    loop Each batch of 500 raw entries
        App->>Conv: getPeerIdentitiesBatch(500, offset)
        Conv-->>App: List<Pair<peerHash, publicKey>>
        App->>App: filter out alreadyRestoredIdentityHashes
        alt batch not empty after filter
            App->>SP: restorePeerIdentities(filtered batch)
            SP-->>App: Result<Int>
        end
        App->>App: offset += 500
    end

_{Last reviewed commit: ac0f9aa}

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@greptile

test failure is not reproducible locally, works for me.

The approach is sound and the measured improvement (~16-18 s → ~5 s splash) validates the change.

Thank you so much for this. I had this random issue so many times. The application logs was not helpful to make a good issue report here.