fix(send): resolve indefinite sync overlay wait (#590)

* fix(send): resolve indefinite sync overlay wait

When a lightning payment starts while channels exist but the peer is not
connected, the send sheet's "Connecting to network" overlay waited forever:
deferred validation early-returns and is only re-triggered by a
hasUsableChannels change that never fires if the peer never connects.

The overlay wait is now bounded to 20 seconds while the device is online.
On timeout, unified invoices take the existing lightning-to-onchain
fallback (the same decision AppViewModel makes at scan time when lightning
cannot pay), and everything else swaps the overlay copy to the existing
"Connection issues" strings while continuing to listen for the peer, with
swipe-down dismissal available throughout.

* chore: rename changelog fragment

* fix(send): restart sync timeout once the node is running

Review follow-up: the timeout task identity now includes node readiness,
so a window that started while the node was still starting restarts at
.running and the unified-invoice onchain fallback can still fire with
fresh balances (previously the Bool id never flipped again and no second
window was scheduled). The long-wait copy is also preserved while the
timer is merely paused by an offline blip, resetting only when the
overlay itself resolves.

* fix(send): show connection issues screen on sync timeout

Review feedback: instead of swapping the sync screen's copy, reuse the
existing OfflineSheetScreen for the timed-out state. OfflineSheetOverlayModifier
gains a forceShow flag so SendSheet can present it when the Lightning peer is
unreachable, not only when the device is offline.

Also clears stale scanned-invoice state when the send sheet opens fresh at
the options route, so closing the sheet during the sync overlay and tapping
Send again no longer reopens the overlay. The reset runs in onAppear for the
options route rather than onDisappear to avoid wiping a freshly scanned
invoice when SheetViewModel hides and re-shows the sheet for an incoming
deep link.

* fix(send): prefer lightning for unified invoices when peer offline

Review feedback: with the node running, unified invoices used to fall back
to onchain immediately when no channel was usable. They now prefer Lightning
and let the send sheet's sync overlay and timeout decide, so a briefly
offline peer no longer forces an onchain payment. No usable channels at all,
or usable channels without capacity, still fall back immediately.

* fix(send): guard routing-fee estimate against zero capacity

Found while testing the unified-invoice path with the peer disconnected:
calculateRoutingFee computed UInt64(maxSendLightningSats) - buffer, which
underflows and traps when maxSendLightningSats is 0 (no usable channel). A
zero-amount Lightning invoice routes to this screen, so the app crashed. With
no usable outbound capacity there is nothing to estimate, so the routing fee
is now 0 and the subtraction is guarded.

* refactor(send): tidy sync timeout additions

Cleanup pass over the PR's changes:
- Collapse the channels-but-unusable check in AppViewModel into a single
  if-let, matching the idiom already used in the pure-bolt11 branch below.
- Use UInt64(clamping:) for the routing-fee capacity conversion instead of
  a hand-rolled max(0, ...) inside a trapping initializer.
- Log shouldShowSyncOverlay on transitions via onChange instead of on every
  evaluation; the new syncTimeoutPhase property raised the per-render
  evaluation count, which tripled identical debug lines in the session log.

Author: CypherPoet

Bitkit/ViewModels/AppViewModel.swift

@@ -387,7 +387,17 @@ extension AppViewModel {
                                 return
                             }
 
-                            // Lightning insufficient for any reason (no channels, no capacity, etc).
+                            // Channels exist but none are usable (e.g. peer offline): still prefer
+                            // lightning. The send sheet shows the sync overlay and either proceeds
+                            // over lightning when the peer reconnects or falls back to onchain
+                            // after its timeout.
+                            if let channels = lightningService.channels, !channels.isEmpty, !channels.contains(where: \.isUsable) {
+                                handleScannedLightningInvoice(lightningInvoice, bolt11: lnInvoice, onchainInvoice: invoice)
+                                return
+                            }
+
+                            // Lightning insufficient for any other reason (no channels at all, or
+                            // usable channels without capacity).
                             // Fall back to onchain and validate onchain balance immediately.
                             let onchainBalance = lightningService.balances?.spendableOnchainBalanceSats ?? 0
                             guard validateOnchainBalance(invoiceAmount: invoice.amountSatoshis, onchainBalance: onchainBalance) else {

Bitkit/Views/Offline/OfflineSheetScreen.swift

@@ -25,12 +25,17 @@ private struct OfflineSheetOverlayModifier: ViewModifier {
     @EnvironmentObject private var network: NetworkMonitor
 
     let title: String
+    var forceShow = false
+
+    private var isShowing: Bool {
+        !network.isConnected || forceShow
+    }
 
     func body(content: Content) -> some View {
         ZStack(alignment: .top) {
             content
 
-            if !network.isConnected {
+            if isShowing {
                 OfflineSheetScreen(title: title)
                     .transition(.opacity)
 
@@ -41,14 +46,15 @@ private struct OfflineSheetOverlayModifier: ViewModifier {
                     .padding(.top, 12)
             }
         }
-        .animation(.easeInOut(duration: 0.3), value: network.isConnected)
+        .animation(.easeInOut(duration: 0.3), value: isShowing)
     }
 }
 
 extension View {
-    /// Overlays a `OfflineSheetScreen` when the device is offline.
+    /// Overlays a `OfflineSheetScreen` when the device is offline, or whenever `forceShow` is true
+    /// (e.g. connection issues beyond device connectivity, like an unreachable Lightning peer).
     /// The underlying content remains mounted so navigation state and inputs are preserved.
-    func offlineSheetOverlay(title: String) -> some View {
-        modifier(OfflineSheetOverlayModifier(title: title))
+    func offlineSheetOverlay(title: String, forceShow: Bool = false) -> some View {
+        modifier(OfflineSheetOverlayModifier(title: title, forceShow: forceShow))
     }
 }

Bitkit/Views/Wallets/Send/SendAmountView.swift

@@ -297,9 +297,20 @@ struct SendAmountView: View {
         guard app.selectedWalletToPayFrom == .lightning else { return }
         guard let bolt11 = app.scannedLightningInvoice?.bolt11 else { return }
 
+        let buffer: UInt64 = 2 // TODO: find out why this is needed
+
+        // Without usable outbound capacity (e.g. peer offline) there is nothing to estimate,
+        // and subtracting the buffer below would underflow `UInt64`.
+        let maxSendable = UInt64(clamping: wallet.maxSendLightningSats)
+        guard maxSendable > buffer else {
+            await MainActor.run {
+                routingFee = 0
+            }
+            return
+        }
+
         do {
-            let buffer: UInt64 = 2 // TODO: find out why this is needed
-            let fee = try await wallet.estimateRoutingFees(bolt11: bolt11, amountSats: UInt64(wallet.maxSendLightningSats) - buffer)
+            let fee = try await wallet.estimateRoutingFees(bolt11: bolt11, amountSats: maxSendable - buffer)
             await MainActor.run {
                 routingFee = fee + buffer
             }

Bitkit/Views/Wallets/Send/SendSheet.swift

@@ -43,6 +43,7 @@ struct SendSheetItem: SheetItem {
 
 struct SendSheet: View {
     @EnvironmentObject private var app: AppViewModel
+    @EnvironmentObject private var network: NetworkMonitor
     @EnvironmentObject private var settings: SettingsViewModel
     @EnvironmentObject private var sheets: SheetViewModel
     @EnvironmentObject private var tagManager: TagManager
@@ -52,15 +53,17 @@ struct SendSheet: View {
 
     @State private var navigationPath: [SendRoute] = []
     @State private var hasValidatedAfterSync = false
+    @State private var syncTimedOut = false
     @State private var pinCheckContinuations: [CheckedContinuation<Bool, Never>] = []
 
+    /// How long the sync overlay may wait for channels to become usable before falling back
+    private static let syncTimeoutSeconds: TimeInterval = 20
+
     /// Show sync overlay when node is not ready for payments
     /// For lightning: need node running AND at least one usable channel (peer connected).
     /// If there are no channels at all, we should NOT wait behind the sync UI – that's a capacity issue, not a sync issue.
     /// For onchain: only need node running.
     private var shouldShowSyncOverlay: Bool {
-        Logger.debug("shouldShowSyncOverlay: \(wallet.nodeLifecycleState)", context: "SendSheet")
-
         // Node must be running
         guard wallet.nodeLifecycleState == .running else { return true }
 
@@ -83,6 +86,22 @@ struct SendSheet: View {
         return false
     }
 
+    /// Identity for the sync timeout task. The timer only counts down while the overlay is visible
+    /// and the device is online (while offline, `offlineSheetOverlay` covers the sheet and a timeout
+    /// would act on stale state). Node readiness is part of the identity so the window restarts when
+    /// the node reaches `.running` mid-wait and the timeout can still fall back with fresh balances.
+    private struct SyncTimeoutPhase: Equatable {
+        let isActive: Bool
+        let isNodeRunning: Bool
+    }
+
+    private var syncTimeoutPhase: SyncTimeoutPhase {
+        SyncTimeoutPhase(
+            isActive: shouldShowSyncOverlay && network.isConnected,
+            isNodeRunning: wallet.nodeLifecycleState == .running
+        )
+    }
+
     var body: some View {
         Sheet(id: .send, data: config) {
             if shouldShowSyncOverlay {
@@ -99,11 +118,21 @@ struct SendSheet: View {
             }
         }
         .animation(.easeInOut(duration: 0.3), value: shouldShowSyncOverlay)
-        .offlineSheetOverlay(title: t("wallet__send_bitcoin"))
+        .offlineSheetOverlay(title: t("wallet__send_bitcoin"), forceShow: syncTimedOut)
+        .onChange(of: shouldShowSyncOverlay, initial: true) { _, isShowing in
+            Logger.debug("shouldShowSyncOverlay: \(isShowing) (node: \(wallet.nodeLifecycleState))", context: "SendSheet")
+        }
         .onAppear {
             tagManager.clearSelectedTags()
             wallet.resetSendState(speed: settings.defaultTransactionSpeed)
             hasValidatedAfterSync = false
+            syncTimedOut = false
+
+            // A plain Send open (TabBar) must not inherit invoice state from an earlier scan,
+            // e.g. one abandoned behind the sync overlay. Invoice-carrying opens use other routes.
+            if config.initialRoute == .options {
+                app.resetSendState()
+            }
 
             Task {
                 do {
@@ -145,6 +174,38 @@ struct SendSheet: View {
                 validatePaymentAfterSync()
             }
         }
+        .task(id: syncTimeoutPhase) {
+            // Bound the sync overlay wait so a peer that never connects can't leave the user
+            // waiting indefinitely (the onChange above only fires if channels become usable).
+            guard syncTimeoutPhase.isActive else {
+                // Reset the connection-issues overlay only once the sync wait actually resolves;
+                // going offline merely pauses the timer and keeps the timed-out state.
+                if !shouldShowSyncOverlay {
+                    syncTimedOut = false
+                }
+                return
+            }
+
+            try? await Task.sleep(for: .seconds(Self.syncTimeoutSeconds))
+            guard !Task.isCancelled, syncTimeoutPhase.isActive, !hasValidatedAfterSync else { return }
+
+            handleSyncTimeout()
+        }
+    }
+
+    /// Called when the sync overlay has been visible for `syncTimeoutSeconds` without channels becoming usable.
+    /// Unified invoices fall back to onchain; everything else shows the connection-issues screen
+    /// (via the forced `offlineSheetOverlay`) and keeps waiting for the peer.
+    private func handleSyncTimeout() {
+        let canFallBackToOnchain = wallet.nodeLifecycleState == .running
+            && app.scannedLightningInvoice != nil
+            && app.scannedOnchainInvoice != nil
+
+        if canFallBackToOnchain {
+            validatePaymentAfterSync(ignoreChannelWait: true)
+        } else {
+            syncTimedOut = true
+        }
     }
 
     /// Validates onchain balance and shows toast + dismisses sheet if insufficient.
@@ -198,15 +259,16 @@ struct SendSheet: View {
     /// Validates payment affordability after sync completes
     /// For lightning: falls back to onchain for unified invoices, shows error for pure lightning invoices
     /// For onchain: validates balance and shows error if insufficient
-    private func validatePaymentAfterSync() {
+    /// Pass `ignoreChannelWait: true` to validate even while channels are unusable (sync timeout).
+    private func validatePaymentAfterSync(ignoreChannelWait: Bool = false) {
         // Validate lightning payment if present
         if let lightningInvoice = app.scannedLightningInvoice {
             // For lightning, if we have channels but none are usable yet, wait for them
             // to become usable. If there are no channels at all, or channels are already
             // usable, proceed with validation/fallback.
             // Use channelCount as fallback in case channels array is nil but count is cached
             let hasAnyChannels = (wallet.channels?.isEmpty == false) || wallet.channelCount > 0
-            if hasAnyChannels, !wallet.hasUsableChannels {
+            if hasAnyChannels, !wallet.hasUsableChannels, !ignoreChannelWait {
                 // We have channels but none usable yet → wait
                 return
             }

changelog.d/next/590.fixed.md

@@ -0,0 +1 @@
+Sending no longer waits indefinitely or crashes when Lightning channels stay unavailable: Bitkit now prefers Lightning while the peer reconnects, then falls back to an onchain payment when possible or shows the connection issues screen after a short wait.