fix: prevent channel monitor loss when remote backup fails

[pwltr]

Fix: Critical Channel Monitor Persistence Bug

🚨 Critical Issue Fixed

This PR resolves a critical bug that could lead to unrecoverable fund loss in multiple failure scenarios involving remote backup operations.

🐛 Problem

• Channel monitor persistence was conditionally dependent on remote backup success
• If remote backup failed (any reason), local persistence was completely skipped
• Multiple failure scenarios could cause fund loss:
  • App killed during backup retries
  • No network connection (permanent backup failure)
  • Network issues during backup
  • Backup server down
• When channel monitor was lost, channels would force-close with "unknown channel" errors
• Result: Permanent loss of channel state and unrecoverable funds

✅ Solution

• Always persist channel monitors locally first (before any remote backup attempts)
• Remote backup failures no longer affect local persistence
• Fixed threading issues in chainMonitor.channelMonitorUpdated() calls
• Channel monitors now survive all network failure scenarios

🔧 Technical Changes

• Move local file write before remote backup queue
• Fix threading issues in chainMonitor.channelMonitorUpdated() calls
• Return ChannelMonitorUpdateStatus.Completed immediately after local persistence
• Bump version

🧪 Testing

• ✅ Reproduced original bug with simulated remote backup failures
• ✅ Verified channel monitors persist despite remote backup failures
• ✅ Confirmed channels remain recoverable after app restart
• ✅ No threading crashes or force-close errors

[pwltr]

This is the PR that initially introduced the bug: #204

[Copilot]

Pull Request Overview

This PR fixes a critical bug where channel monitor persistence was conditional on remote backup success, potentially causing unrecoverable fund loss. The fix ensures channel monitors are always persisted locally first, regardless of remote backup status.

Key Changes:

• Local channel monitor persistence now occurs before remote backup attempts
• Remote backup failures no longer block or skip local persistence
• Threading issues in chainMonitor.channelMonitorUpdated() calls are fixed by dispatching to main/UI thread

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
lib/package.json	Version bump from 0.0.160 to 0.0.161
lib/ios/Classes/LdkPersist.swift	Reordered persistence to write locally first, moved remote backup to async callback, fixed threading for chain monitor update
lib/android/src/main/java/com/reactnativeldk/classes/LdkPersister.kt	Reordered persistence to write locally first, moved remote backup to async callback, fixed threading for chain monitor update

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[ovitrif]

LGTM, didn't test but the changeset reads easy, and I trust the author :D

[coreyphillips]

As the copilot comment mentioned, is there any reason we shouldn't re-add the new channel event emitters beneath the local writes?

Android:

file.writeBytes(serialized)
if (isNew) {
      LdkEventEmitter.send(EventTypes.new_channel, body)
}

iOS:

try serialized.write(to: channelStoragePath)
if isNew {
      LdkEventEmitter.shared.send(withEvent: .new_channel, body: body)
}

[ben-kaufman]

@coreyphillips I'm not so familiar with the code so maybe I'm wrong but I think it does call the new channel event since it no longer returns right after saving locally, so new channel event is now emitted in line 38 in Android and line 46 iOS. So that seems like a false positive issue from copilot.

[ben-kaufman]

utACK

[ovitrif]

@pwltr Will you add a PR to integrate this fix into Bitkit? Thx 🙏🏻 .