log when listpays verification itself errors

When ln.listpays throws inside the post-failure verification path in
sendLightning / sendKeysend, the outer catch was swallowing it silently.
That meant a CLN outage during a failing payment was indistinguishable
from clean failure-and-reverse in the logs.

We still want to not-reverse in this case (the debit stays, pending stays
in the reconciler set, check() retries when CLN is back), but the
operator deserves to know the verification step failed. Logged via
warnThrottled so a multi-hour outage doesn't flood the log.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

1 files changed, 10 insertions, 2 deletions

diff --git a/lib/payments.ts b/lib/payments.ts
index 6c78f40e..22bbafb4 100644
--- a/lib/payments.ts
+++ b/lib/payments.ts
@@ -586,7 +586,9 @@ export const sendKeysend = async ({
       // else: pending or completed — leave the debit; check() loop will
       // reconcile. Reversing on pending would refund while CLN may still
       // settle the keysend.
-    } catch (_) {}
+    } catch (verifyErr: any) {
+      warnThrottled("listpays verification failed (keysend)", verifyErr?.message ?? String(verifyErr));
+    }
     throw e;
   }
 };
@@ -673,7 +675,13 @@ export const sendLightning = async ({
       // else: pending — leave the debit in place; check() loop will reconcile
       // once CLN confirms outcome. Reversing while still in flight would
       // refund the user even though the payment may yet complete.
-    } catch (_) {}
+    } catch (verifyErr: any) {
+      // listpays itself errored (CLN unreachable). We deliberately don't
+      // reverse here — the debit stays and pending stays in the reconciler
+      // set, so check() will retry once CLN is back. Surface the failure so
+      // a real outage doesn't go unnoticed.
+      warnThrottled("listpays verification failed", verifyErr?.message ?? String(verifyErr));
+    }
     throw e;
   }