chore: version 2.1.2

[ovitrif]

Fixes: #847

Release 2.1.2 — includes stale channel monitors recovery and version bump.

Note: This PR replaces #855 which was auto-closed by GitHub when the base branch was force-pushed. It could not be reopened, so this release PR supersedes it.

see also:

• feat: accept stale channel monitors for recovery ldk-node#76
• feat: stale channel monitors recovery bitkit-ios#502

Description

• Stale channel monitors recovery: When a channel monitor falls behind the channel manager (e.g. due to faulty overwrite during an unfiltered migration from LDK to ldk-node), ldk-node refuses to start with a DangerousValue error to protect funds. This catches that error and retries the build with accept_stale_channel_monitors enabled, allowing ldk-node to accept the stale monitor and self-heal via commitment round-trips with the channel peer.
• Adds a 10s connection timeout to the node config, as required by ldk-node rc.33.
• versionCode: 179 → 180
• versionName: 2.1.1 → 2.1.2

Preview

Screenshot of activity list after recovery.
The transactions are part of the setup to reproduce the issue.

QA Notes

1. Normal startup (unaffected users)

1. Install the build on a device with an existing wallet
2. Launch the app
3. Verify the node starts normally with no warnings in logs
4. Verify all balances and channels appear correctly

2. Stale monitor recovery

1. Reproduce the stale monitor state, see test plan
2. App should be in broken state now: node fails to start
3. Run 2.1.2
4. Verify the healing fix succeeds and app starts with a fully functional node and LN channel
5. Check logs for DangerousValue and accept_stale_channel_monitors
6. Verify Stale monitor recovery: all monitors healed appears in logs within ~15s
7. Kill and relaunch — verify normal startup & no retry logs, since monitors are now healed

3. Connection timeout (optional)

1. Verify the node respects the 10s connection timeout (observable in poor network conditions)

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

[piotr-iohk]

Exercised the full matrix in repro-channel-monitor-desync.md#test-plan against this build. All targeted scenarios passed.

Observations (I believe non-blocking, but sharing to double-check):

• Scenario B7 (Blocktank channel: v2.1.0 broken wallet + 600 blocks mined → v2.1.2 (stale chain state)): Recovery completed (DangerousValue → setAcceptStaleChannelMonitors, healing payment, monitors healed). Immediately after startup, LN send/receive briefly showed “route not found” toast; after a short time / a few attempts, payments succeeded. Likely regtest RGS empty/stale + graph warm-up rather than a failed recovery. Sharing logs to double check.
  logs-b7-android.zip

• Scenarios T2 / T5 (3rd-party / local LND: Update broken v2.1.0 wallet to v2.1.2): Recovery/end-to-end took longer than Blocktank cases; run hit a timeout. In the end it recovered, but took over a minute in both cases
  logs-t2-android.zip
  logs-t5-android.zip

[jvsena42]

Exercised the full matrix in repro-channel-monitor-desync.md#test-plan against this build. All targeted scenarios passed.

Observations (I believe non-blocking, but sharing to double-check):

• Scenario B7 (Blocktank channel: v2.1.0 broken wallet + 600 blocks mined → v2.1.2 (stale chain state)): Recovery completed (DangerousValue → setAcceptStaleChannelMonitors, healing payment, monitors healed). Immediately after startup, LN send/receive briefly showed “route not found” toast; after a short time / a few attempts, payments succeeded. Likely regtest RGS empty/stale + graph warm-up rather than a failed recovery. Sharing logs to double check.
  logs-b7-android.zip
• Scenarios T2 / T5 (3rd-party / local LND: Update broken v2.1.0 wallet to v2.1.2): Recovery/end-to-end took longer than Blocktank cases; run hit a timeout. In the end it recovered, but took over a minute in both cases
  logs-t2-android.zip
  logs-t5-android.zip

✅ Confirmed, these are non-blocking behaviors. From the logs:

• B7 : The recovery succeed, but the network graph was reject as stale "Rapid Gossip Sync data is more than two weeks old" with RGS timestamp = 0, and then succeeds once graph populates. This is an expected behavior in regtest. On mainnet, RGS will have a valid snapshot, so the graph won't be empty after recovery. The aresRequiredPeersInNetworkGraph() validation at LightningRepo.kt:336 would also catch and reset a stale graph on mainnet if needed.

• T2/T5: The recover also succeeded eventually. LND took longer because it rejected the healing payment with IncorrectPaymentDetails, so the remaining path to healing was waiting for normal channel reestablishment after the timeout