Summary
When cancelHoldInvoice fails (e.g. LND is temporarily unreachable), all call
sites in bot/commands.ts and bot/start.ts catch the error via their outer
try/catch, log it, and return — without sending any message to the user.
The operation simply doesn't complete, and the user has no way of knowing
something went wrong.
Background
Prior to #884, cancelHoldInvoice swallowed LND errors internally — it would
catch the failure, log it, and return undefined as if nothing had happened.
Callers had no way to detect a failure, so they would proceed to mark orders
as CANCELED, CANCELED_BY_ADMIN, or SELLER_REFUNDED even when the hold
invoice was never actually canceled. #884 fixed this by making
cancelHoldInvoice re-throw LND errors, consistent with settleHoldInvoice.
This made the failure visible to callers — but exposed that the command-based
call sites don't handle it with user feedback.
Affected call sites
bot/commands.ts:322 — seller cancels in WAITING_PAYMENTbot/commands.ts:534 — buyer cancels in WAITING_BUYER_INVOICEbot/commands.ts:711 — cooperative cancelbot/commands.ts:790 — admin cancelbot/start.ts:445 — admin cancel (alternate path)bot/start.ts:534 — cancel all orders
Current behavior
LND fails → error is caught and logged → user sees nothing → order stays
in its current state.
Expected behavior
LND fails → user receives an error message explaining the operation failed
and they can retry.
Notes
- The job-based call sites (
cancel_orders.ts, check_hold_invoice_expired.ts)
are fine — they retry automatically on the next run.
- A generic LND error message function may already exist in
bot/messages.ts
— worth checking before adding new ones.
Summary
When
cancelHoldInvoicefails (e.g. LND is temporarily unreachable), all callsites in
bot/commands.tsandbot/start.tscatch the error via their outertry/catch, log it, and return — without sending any message to the user.The operation simply doesn't complete, and the user has no way of knowing
something went wrong.
Background
Prior to #884,
cancelHoldInvoiceswallowed LND errors internally — it wouldcatch the failure, log it, and return
undefinedas if nothing had happened.Callers had no way to detect a failure, so they would proceed to mark orders
as
CANCELED,CANCELED_BY_ADMIN, orSELLER_REFUNDEDeven when the holdinvoice was never actually canceled. #884 fixed this by making
cancelHoldInvoicere-throw LND errors, consistent withsettleHoldInvoice.This made the failure visible to callers — but exposed that the command-based
call sites don't handle it with user feedback.
Affected call sites
bot/commands.ts:322— seller cancels inWAITING_PAYMENTbot/commands.ts:534— buyer cancels inWAITING_BUYER_INVOICEbot/commands.ts:711— cooperative cancelbot/commands.ts:790— admin cancelbot/start.ts:445— admin cancel (alternate path)bot/start.ts:534— cancel all ordersCurrent behavior
LND fails → error is caught and logged → user sees nothing → order stays
in its current state.
Expected behavior
LND fails → user receives an error message explaining the operation failed
and they can retry.
Notes
cancel_orders.ts,check_hold_invoice_expired.ts)are fine — they retry automatically on the next run.
bot/messages.ts— worth checking before adding new ones.