feat: one-time stale channel monitor recovery (v2)#501
feat: one-time stale channel monitor recovery (v2)#501
Conversation
On BuildError.ReadFailed (likely stale ChannelMonitor from migration overwrite), automatically retry once with accept_stale_channel_monitors enabled. The ldk-node recovery flag force-syncs the monitor's update_id and heals commitment state via a delayed chain sync + keysend round-trip. A persisted UserDefaults flag ensures this only triggers once — set on any successful build (affected or not), preventing future retries. Depends on: synonymdev/ldk-node#76 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
on draft to wait for bindings |
| throw error | ||
| } | ||
|
|
||
| // Build failed with ReadFailed — likely a stale ChannelMonitor (DangerousValue). |
There was a problem hiding this comment.
Replace with specific exception
| context: "Recovery" | ||
| ) | ||
| Self.staleMonitorRecoveryAttempted = true | ||
| builder.setAcceptStaleChannelMonitors(accept: true) |
There was a problem hiding this comment.
Missing dependency: setAcceptStaleChannelMonitors not in pinned ldk-node revision
This call references builder.setAcceptStaleChannelMonitors(accept: true), but the method does not exist in the currently pinned synonymdev/ldk-node revision (c5698d0, set in Bitkit.xcodeproj). As a result, this branch will not compile until the project.pbxproj is updated to a commit that includes synonymdev/ldk-node#76 (which the PR description already calls out as a requirement).
bitkit-ios/Bitkit/Services/LightningService.swift
Lines 163 to 167 in db59970
|
best to align this with the android counterpart: |
|
replaced by #502 |
Description
This PR adds automatic one-time recovery for users affected by stale channel monitors caused by the RN migration overwrite bug (#462, #495).
On
BuildError.ReadFailed, the app automatically retries the LDK node build once withaccept_stale_channel_monitorsenabled. A persistedstaleMonitorRecoveryAttemptedUserDefaults flag ensures this only happens once — the flag is set on any successful build, so unaffected users see zero impact.This is a clean cherry-pick of the recovery logic from #500 onto
release-2.1.1, without the unrelated pubky work that was in the original branch.Linked Issues/Tasks
Screenshot / Video
N/A - backend logic change
QA Notes
🤖 Generated with Claude Code