Funds-relevant failures are logged and treated as success (no durable retry or cleanup obligation)

Summary

Several channel-lifecycle steps catch an error, write a log line and then continue as if the step had succeeded. In each case nothing durable records that the work is still owed. The node can therefore end up with locked UTXOs, an unreleased RGB allocation, a transaction the network never accepted, or an asset that was never imported — while every API response, event and log line indicates normal progress. Because there is no persisted "obligation", a restart does not repair it either.

Details

1. A failed force-close after a funding-preparation error returns Ok

handle_funding_prepare_err force-closes the channel on a terminal rgb-lib error. If force_close_broadcasting_latest_txn itself fails, the error is logged and the handler returns Ok(()). The event is acknowledged, the channel may still exist in LDK, and nothing records that cleanup is pending.

2. A failed release of locked funds is logged — and then the pointer to the funds is deleted

handle_open_chan_fail (run on ChannelClosed / DiscardFunding) fails the RGB batch transfer or aborts the pending vanilla tx. On error it only logs, then unconditionally removes the PENDING_FUNDING record, so a later retry can no longer find the txid. abort_staged_standard_funding is explicitly "best-effort: errors are logged and the caller still replays the event" — the replayed event stages a new transfer while the old reservation may still be held.

3. A funding hand-off failure after signing has no cleanup at all

In FundingGenerationReady, once the PSBT is signed, the batch transfer staged, the consignment posted to the proxy and the PSBT / PENDING_FUNDING records written, the funding transaction is handed to funding_transaction_generated. If that returns an error (peer disconnected, channel already gone) the handler only logs "Channel went away before we could fund it". Whether a ChannelClosed event still follows depends on LDK's state at that moment; if it was already emitted (before the PENDING_FUNDING record existed), the locked UTXOs / RGB allocation are never released.

4. Broadcast results are never observed

broadcast_transactions spawns a detached task; a sendrawtransaction / submitpackage rejection is logged as "likely okay". Inside the task, e.get_ref().unwrap() panics for an io::Error that carries no inner error (transport-level failures), silently killing the task. For closing, claim and sweep transactions a rejected or never-sent transaction is indistinguishable from a successful broadcast until some later rebroadcast — if one happens.

5. RGB refresh results on ChannelReady are discarded

The handler runs rgb_refresh twice inside spawn_blocking and unwrap()s both. The returned per-transfer results (rgb-lib reports individual transfer failures inside an Ok) are dropped: a transfer that failed to settle is neither retried nor surfaced, and an Err panics the event task.

6. Acceptor asset import: the consignment is deleted before the import succeeds, and UNIQUE errors are swallowed

In the acceptor branch of ChannelPending, remove_rgb_consignment(funding_txid) runs before rgb_save_new_asset. If the import fails the handler panics and the consignment is already gone, so a replay cannot redo it. Any error whose message contains UNIQUE constraint failed is treated as success, regardless of which table or row it refers to.

Impact

• Locked funds and reserved RGB allocations that are never released after a failed open.
• Funding attempts that stay half-open with no owner.
• Close / claim transactions that the network never accepted, with no alert and no retry.
• Assets that were never imported on the acceptor side.

All of this while /openchannel, /listchannels and the logs report success.

Start by tracing handle_funding_prepare_err, handle_open_chan_fail, FundingGenerationReady, broadcast_transactions, ChannelReady, and the acceptor branch of ChannelPending. Map each failure path to its persisted state and event behavior, then determine how completion, retry, cleanup, and failure reporting should be verified; the issue does not name specific files or tests.