Allow cancellation of pending splice funding negotiations

[wpaulino]

A user may wish to cancel an in-flight funding negotiation for whatever reason (e.g., mempool feerates have gone down, inability to sign, etc.), so we should make it possible for them to do so. Note that this can only be done for splice funding negotiations for which the user has made a contribution to.

[ldk-reviews-bot]

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[ldk-claude-review-bot]

This .expect() can panic in release builds. While cancel_splice in channel.rs verifies made_contribution is true, the maybe_create_splice_funding_failed! macro additionally subtracts contributions that overlap with prior RBF rounds (via prior_contributed_inputs/outputs). For a non-initiator who reuses the same UTXOs across RBF attempts with no explicit output contributions, the subtraction can empty the lists, causing the macro to return None (line 6740-6742 of channel.rs: if !is_initiator && contributed_inputs.is_empty() && contributed_outputs.is_empty() { return None; }).

The debug_assert!(splice_funding_failed.is_some()) at channel.rs:12323 catches this in debug, but this expect will crash in release for that edge case. Consider handling None gracefully, e.g. by returning an APIError or skipping the events.

[wpaulino]

@jkczyz looks like that if statement it's referring to is indeed happening after the filtering. We should check whether the contribution is empty prior to filtering. I also noticed that we'll always emit DiscardFunding even when both contributed inputs and outputs are empty, we should only do so when there is actually something to discard.

[jkczyz]

@jkczyz looks like that if statement it's referring to is indeed happening after the filtering. We should check whether the contribution is empty prior to filtering.

Hmm... we may want to base this on #4514. It refactors that code a bit and removes maybe_create_splice_funding_failed!. I believe the new splice_funding_failed_for! macro does it correctly now (dc0609d)

I also noticed that we'll always emit DiscardFunding even when both contributed inputs and outputs are empty, we should only do so when there is actually something to discard.

I believe that is fixed in #4514, too. Can't recall if it's the same commit, but the PR should consolidate the filtering logic to FundingContribution::into_unique_contributions.

[ldk-claude-review-bot]

I've completed a thorough review of the entire PR diff, examining every hunk and cross-referencing with the codebase. All prior review comments have been verified against the current code.

Two prior comments appear to be resolved in the current code:

• events/mod.rs:193 — Display string is now correctly "splice locally canceled"
• interactivetxs.rs:142 — Doc link now resolves correctly

Review Summary

No new issues found beyond those flagged in the prior review pass. The remaining prior findings that are still applicable:

1. lightning/src/ln/channelmanager.rs:4942 — debug_assert!(splice_funding_failed.is_some()) / potential release-mode silent event loss for non-initiator RBF edge case where splice_funding_failed_for! macro filters all contributions to None.
2. lightning/src/ln/channel.rs:12830 — has_local_contribution() vs contributed_inputs()/contributed_outputs() use different computation paths for the same semantic check across FundingNegotiation variants.
3. lightning/src/ln/channelmanager.rs:4941 — PersistenceNotifierGuard::manually_notify does not set needs_persist_flag. While the explicit event_persist_notifier.notify() at line 4978 ensures prompt event delivery, channel state changes (splice reset, quiescence exit) won't be persisted until an unrelated trigger. If the node crashes before then, the cancel is lost and the splice may resume on reconnection.
4. lightning/src/ln/splicing_tests.rs:3140 — if state == 0 is unreachable dead code since that case returns early at line 3152.

Verification notes

• The counterparty_aborted → allow_resumption boolean inversion is correct across all 9 call sites (verified each one).
• Lock ordering in cancel_funding_contributed is correct — peer/channel locks dropped before handle_interactive_tx_msg_err/handle_error.
• The debug_assert!(self.should_reset_pending_splice_state(false)) in reset_pending_splice_state holds for the cancel_funding_contributed path because: has_holder_tx_signatures()=false implies has_received_commitment_signed()=false (counterparty's commitment_signed is stashed until funding_transaction_signed is called).
• The quiescent_action cancellation path correctly handles three sub-cases: stfu not yet sent (Ignore), stfu sent but not received (WarnAndDisconnect), and both stfus exchanged (Ignore — counterparty's splice continues unaffected).
• No TOCTOU risk between the has_holder_tx_signatures() check and reset_pending_splice_state since both run under the peer_state lock.
• TLV tag 11 is reused for LocallyCanceled (renamed from LocallyAbandoned), maintaining wire compatibility.

[jkczyz]

Do we need to worry about updating PendingFunding::contributions when reseting? This may be a pre-existing issue, though.

[wpaulino]

Already fixed in a547960.

[ldk-reviews-bot]

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 2nd Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 3rd Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 4th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 5th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 6th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-claude-review-bot]

The previous abandon_splice used PersistenceNotifierGuard::optionally_notify and returned NotifyOption::SkipPersistHandleEvents on success, which would wake up the background processor to deliver the newly-added SpliceFailed/DiscardFunding events and the tx_abort message promptly.

manually_notify delegates the notification decision to process_background_events(), which returns SkipPersistNoEvents when there are no pending background events. This means when no holding-cell HTLCs are freed (the handle_holding_cell_free_result path that calls notify()), the background processor is never woken up. Events and messages sit in memory until the next polling interval or until some unrelated activity triggers notification.

This is also a persistence concern: the splice state reset and quiescence exit modify channel state, but without notification, persistence may not happen until the next trigger. If the node crashes in between, the cancel is effectively lost (though the reestablishment protocol handles recovery).

Consider using optionally_notify (returning SkipPersistHandleEvents on success, SkipPersistNoEvents on error) to match the behavior of other public APIs like funding_contributed and funding_transaction_signed.

[ldk-claude-review-bot]

Dead code: state == 0 can never be true here because that case returned early at line 2990. The if branch is unreachable — only the else ever runs.

Suggested change

	acceptor.node.handle_tx_abort(node_id_initiator, tx_abort);
	if state == 0{
	assert!(acceptor.node.get_and_clear_pending_msg_events().is_empty());
	acceptor.node.handle_tx_abort(node_id_initiator, tx_abort);
	{
	let tx_abort = get_event_msg!(acceptor,MessageSendEvent::SendTxAbort, node_id_initiator);

[codecov]

Codecov Report

❌ Patch coverage is 81.60000% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.11%. Comparing base (c766417) to head (637cc41).
⚠️ Report is 17 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	72.54%	13 Missing and 1 partial ⚠️
lightning/src/ln/channel.rs	88.88%	8 Missing ⚠️
lightning/src/events/mod.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4490 +/- ##
=======================================
Coverage 86.11% 86.11% =======================================
Files 157 157 Lines 108851 108817 -34 Branches 108851 108817 -34 =======================================
- Hits 93735 93706 -29 + Misses 12503 12494 -9 - Partials 2613 2617 +4 

Flag	Coverage Δ
tests	86.11% <81.60%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[TheBlueMatt]

please add calls to this in the fuzzer.

[wpaulino]

I'll look into adding this when I restore splicing in the fuzzer

[TheBlueMatt]

Does this suffice? We call reset_pending_splice_state which asserts that !has_received_commitment_signed() but we don't check it here?

[wpaulino]

We can only process the counterparty's initial commitment_signed once the user calls back with ChannelManager::funding_transaction_signed.

[ldk-reviews-bot]

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[jkczyz]

CI is unhappy. One of my PRs added a parameter to one of the test helpers. So probably need a rebase.

[TheBlueMatt]

Needs rebase now

[TheBlueMatt]

This really feels like it should be coming from the channel in the InteractiveTxMsgError, not set randomly here.

[wpaulino]

A user may wish to cancel an in-flight funding negotiation for whatever reason (e.g., mempool feerates have gone down, inability to sign, etc.), so we should make it possible for them to do so. Note that this can only be done for splice funding negotiations for which the user has made a contribution to.

[ldk-reviews-bot]

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[ldk-claude-review-bot]

This .expect() can panic in release builds. While cancel_splice in channel.rs verifies made_contribution is true, the maybe_create_splice_funding_failed! macro additionally subtracts contributions that overlap with prior RBF rounds (via prior_contributed_inputs/outputs). For a non-initiator who reuses the same UTXOs across RBF attempts with no explicit output contributions, the subtraction can empty the lists, causing the macro to return None (line 6740-6742 of channel.rs: if !is_initiator && contributed_inputs.is_empty() && contributed_outputs.is_empty() { return None; }).

The debug_assert!(splice_funding_failed.is_some()) at channel.rs:12323 catches this in debug, but this expect will crash in release for that edge case. Consider handling None gracefully, e.g. by returning an APIError or skipping the events.

[wpaulino]

@jkczyz looks like that if statement it's referring to is indeed happening after the filtering. We should check whether the contribution is empty prior to filtering. I also noticed that we'll always emit DiscardFunding even when both contributed inputs and outputs are empty, we should only do so when there is actually something to discard.

[jkczyz]

@jkczyz looks like that if statement it's referring to is indeed happening after the filtering. We should check whether the contribution is empty prior to filtering.

Hmm... we may want to base this on #4514. It refactors that code a bit and removes maybe_create_splice_funding_failed!. I believe the new splice_funding_failed_for! macro does it correctly now (dc0609d)

I also noticed that we'll always emit DiscardFunding even when both contributed inputs and outputs are empty, we should only do so when there is actually something to discard.

I believe that is fixed in #4514, too. Can't recall if it's the same commit, but the PR should consolidate the filtering logic to FundingContribution::into_unique_contributions.

[ldk-claude-review-bot]

I've completed a thorough review of the entire PR diff, examining every hunk and cross-referencing with the codebase. All prior review comments have been verified against the current code.

Two prior comments appear to be resolved in the current code:

• events/mod.rs:193 — Display string is now correctly "splice locally canceled"
• interactivetxs.rs:142 — Doc link now resolves correctly

Review Summary

No new issues found beyond those flagged in the prior review pass. The remaining prior findings that are still applicable:

1. lightning/src/ln/channelmanager.rs:4942 — debug_assert!(splice_funding_failed.is_some()) / potential release-mode silent event loss for non-initiator RBF edge case where splice_funding_failed_for! macro filters all contributions to None.
2. lightning/src/ln/channel.rs:12830 — has_local_contribution() vs contributed_inputs()/contributed_outputs() use different computation paths for the same semantic check across FundingNegotiation variants.
3. lightning/src/ln/channelmanager.rs:4941 — PersistenceNotifierGuard::manually_notify does not set needs_persist_flag. While the explicit event_persist_notifier.notify() at line 4978 ensures prompt event delivery, channel state changes (splice reset, quiescence exit) won't be persisted until an unrelated trigger. If the node crashes before then, the cancel is lost and the splice may resume on reconnection.
4. lightning/src/ln/splicing_tests.rs:3140 — if state == 0 is unreachable dead code since that case returns early at line 3152.

Verification notes

• The counterparty_aborted → allow_resumption boolean inversion is correct across all 9 call sites (verified each one).
• Lock ordering in cancel_funding_contributed is correct — peer/channel locks dropped before handle_interactive_tx_msg_err/handle_error.
• The debug_assert!(self.should_reset_pending_splice_state(false)) in reset_pending_splice_state holds for the cancel_funding_contributed path because: has_holder_tx_signatures()=false implies has_received_commitment_signed()=false (counterparty's commitment_signed is stashed until funding_transaction_signed is called).
• The quiescent_action cancellation path correctly handles three sub-cases: stfu not yet sent (Ignore), stfu sent but not received (WarnAndDisconnect), and both stfus exchanged (Ignore — counterparty's splice continues unaffected).
• No TOCTOU risk between the has_holder_tx_signatures() check and reset_pending_splice_state since both run under the peer_state lock.
• TLV tag 11 is reused for LocallyCanceled (renamed from LocallyAbandoned), maintaining wire compatibility.

[jkczyz]

Do we need to worry about updating PendingFunding::contributions when reseting? This may be a pre-existing issue, though.

[wpaulino]

Already fixed in a547960.

[ldk-reviews-bot]

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 2nd Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 3rd Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 4th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 5th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 6th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-claude-review-bot]

The previous abandon_splice used PersistenceNotifierGuard::optionally_notify and returned NotifyOption::SkipPersistHandleEvents on success, which would wake up the background processor to deliver the newly-added SpliceFailed/DiscardFunding events and the tx_abort message promptly.

manually_notify delegates the notification decision to process_background_events(), which returns SkipPersistNoEvents when there are no pending background events. This means when no holding-cell HTLCs are freed (the handle_holding_cell_free_result path that calls notify()), the background processor is never woken up. Events and messages sit in memory until the next polling interval or until some unrelated activity triggers notification.

This is also a persistence concern: the splice state reset and quiescence exit modify channel state, but without notification, persistence may not happen until the next trigger. If the node crashes in between, the cancel is effectively lost (though the reestablishment protocol handles recovery).

Consider using optionally_notify (returning SkipPersistHandleEvents on success, SkipPersistNoEvents on error) to match the behavior of other public APIs like funding_contributed and funding_transaction_signed.

[ldk-claude-review-bot]

Dead code: state == 0 can never be true here because that case returned early at line 2990. The if branch is unreachable — only the else ever runs.

Suggested change

	acceptor.node.handle_tx_abort(node_id_initiator, tx_abort);
	if state == 0{
	assert!(acceptor.node.get_and_clear_pending_msg_events().is_empty());
	acceptor.node.handle_tx_abort(node_id_initiator, tx_abort);
	{
	let tx_abort = get_event_msg!(acceptor,MessageSendEvent::SendTxAbort, node_id_initiator);

[codecov]

Codecov Report

❌ Patch coverage is 81.60000% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.11%. Comparing base (c766417) to head (637cc41).
⚠️ Report is 17 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	72.54%	13 Missing and 1 partial ⚠️
lightning/src/ln/channel.rs	88.88%	8 Missing ⚠️
lightning/src/events/mod.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4490 +/- ##
=======================================
Coverage 86.11% 86.11% =======================================
Files 157 157 Lines 108851 108817 -34 Branches 108851 108817 -34 =======================================
- Hits 93735 93706 -29 + Misses 12503 12494 -9 - Partials 2613 2617 +4 

Flag	Coverage Δ
tests	86.11% <81.60%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[TheBlueMatt]

please add calls to this in the fuzzer.

[wpaulino]

I'll look into adding this when I restore splicing in the fuzzer

[TheBlueMatt]

Does this suffice? We call reset_pending_splice_state which asserts that !has_received_commitment_signed() but we don't check it here?

[wpaulino]

We can only process the counterparty's initial commitment_signed once the user calls back with ChannelManager::funding_transaction_signed.

[ldk-reviews-bot]

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[jkczyz]

CI is unhappy. One of my PRs added a parameter to one of the test helpers. So probably need a rebase.

[TheBlueMatt]

Needs rebase now

[TheBlueMatt]

This really feels like it should be coming from the channel in the InteractiveTxMsgError, not set randomly here.

[wpaulino]

A user may wish to cancel an in-flight funding negotiation for whatever reason (e.g., mempool feerates have gone down, inability to sign, etc.), so we should make it possible for them to do so. Note that this can only be done for splice funding negotiations for which the user has made a contribution to.

[ldk-reviews-bot]

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[ldk-claude-review-bot]

This .expect() can panic in release builds. While cancel_splice in channel.rs verifies made_contribution is true, the maybe_create_splice_funding_failed! macro additionally subtracts contributions that overlap with prior RBF rounds (via prior_contributed_inputs/outputs). For a non-initiator who reuses the same UTXOs across RBF attempts with no explicit output contributions, the subtraction can empty the lists, causing the macro to return None (line 6740-6742 of channel.rs: if !is_initiator && contributed_inputs.is_empty() && contributed_outputs.is_empty() { return None; }).

The debug_assert!(splice_funding_failed.is_some()) at channel.rs:12323 catches this in debug, but this expect will crash in release for that edge case. Consider handling None gracefully, e.g. by returning an APIError or skipping the events.

[wpaulino]

@jkczyz looks like that if statement it's referring to is indeed happening after the filtering. We should check whether the contribution is empty prior to filtering. I also noticed that we'll always emit DiscardFunding even when both contributed inputs and outputs are empty, we should only do so when there is actually something to discard.

[jkczyz]

@jkczyz looks like that if statement it's referring to is indeed happening after the filtering. We should check whether the contribution is empty prior to filtering.

Hmm... we may want to base this on #4514. It refactors that code a bit and removes maybe_create_splice_funding_failed!. I believe the new splice_funding_failed_for! macro does it correctly now (dc0609d)

I also noticed that we'll always emit DiscardFunding even when both contributed inputs and outputs are empty, we should only do so when there is actually something to discard.

I believe that is fixed in #4514, too. Can't recall if it's the same commit, but the PR should consolidate the filtering logic to FundingContribution::into_unique_contributions.

[ldk-claude-review-bot]

I've completed a thorough review of the entire PR diff, examining every hunk and cross-referencing with the codebase. All prior review comments have been verified against the current code.

Two prior comments appear to be resolved in the current code:

• events/mod.rs:193 — Display string is now correctly "splice locally canceled"
• interactivetxs.rs:142 — Doc link now resolves correctly

Review Summary

No new issues found beyond those flagged in the prior review pass. The remaining prior findings that are still applicable:

1. lightning/src/ln/channelmanager.rs:4942 — debug_assert!(splice_funding_failed.is_some()) / potential release-mode silent event loss for non-initiator RBF edge case where splice_funding_failed_for! macro filters all contributions to None.
2. lightning/src/ln/channel.rs:12830 — has_local_contribution() vs contributed_inputs()/contributed_outputs() use different computation paths for the same semantic check across FundingNegotiation variants.
3. lightning/src/ln/channelmanager.rs:4941 — PersistenceNotifierGuard::manually_notify does not set needs_persist_flag. While the explicit event_persist_notifier.notify() at line 4978 ensures prompt event delivery, channel state changes (splice reset, quiescence exit) won't be persisted until an unrelated trigger. If the node crashes before then, the cancel is lost and the splice may resume on reconnection.
4. lightning/src/ln/splicing_tests.rs:3140 — if state == 0 is unreachable dead code since that case returns early at line 3152.

Verification notes

• The counterparty_aborted → allow_resumption boolean inversion is correct across all 9 call sites (verified each one).
• Lock ordering in cancel_funding_contributed is correct — peer/channel locks dropped before handle_interactive_tx_msg_err/handle_error.
• The debug_assert!(self.should_reset_pending_splice_state(false)) in reset_pending_splice_state holds for the cancel_funding_contributed path because: has_holder_tx_signatures()=false implies has_received_commitment_signed()=false (counterparty's commitment_signed is stashed until funding_transaction_signed is called).
• The quiescent_action cancellation path correctly handles three sub-cases: stfu not yet sent (Ignore), stfu sent but not received (WarnAndDisconnect), and both stfus exchanged (Ignore — counterparty's splice continues unaffected).
• No TOCTOU risk between the has_holder_tx_signatures() check and reset_pending_splice_state since both run under the peer_state lock.
• TLV tag 11 is reused for LocallyCanceled (renamed from LocallyAbandoned), maintaining wire compatibility.

[jkczyz]

Do we need to worry about updating PendingFunding::contributions when reseting? This may be a pre-existing issue, though.

[wpaulino]

Already fixed in a547960.

[ldk-reviews-bot]

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 2nd Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 3rd Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 4th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 5th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 6th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-claude-review-bot]

The previous abandon_splice used PersistenceNotifierGuard::optionally_notify and returned NotifyOption::SkipPersistHandleEvents on success, which would wake up the background processor to deliver the newly-added SpliceFailed/DiscardFunding events and the tx_abort message promptly.

manually_notify delegates the notification decision to process_background_events(), which returns SkipPersistNoEvents when there are no pending background events. This means when no holding-cell HTLCs are freed (the handle_holding_cell_free_result path that calls notify()), the background processor is never woken up. Events and messages sit in memory until the next polling interval or until some unrelated activity triggers notification.

This is also a persistence concern: the splice state reset and quiescence exit modify channel state, but without notification, persistence may not happen until the next trigger. If the node crashes in between, the cancel is effectively lost (though the reestablishment protocol handles recovery).

Consider using optionally_notify (returning SkipPersistHandleEvents on success, SkipPersistNoEvents on error) to match the behavior of other public APIs like funding_contributed and funding_transaction_signed.

[ldk-claude-review-bot]

Dead code: state == 0 can never be true here because that case returned early at line 2990. The if branch is unreachable — only the else ever runs.

Suggested change

	acceptor.node.handle_tx_abort(node_id_initiator, tx_abort);
	if state == 0{
	assert!(acceptor.node.get_and_clear_pending_msg_events().is_empty());
	acceptor.node.handle_tx_abort(node_id_initiator, tx_abort);
	{
	let tx_abort = get_event_msg!(acceptor,MessageSendEvent::SendTxAbort, node_id_initiator);

[codecov]

Codecov Report

❌ Patch coverage is 81.60000% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.11%. Comparing base (c766417) to head (637cc41).
⚠️ Report is 17 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	72.54%	13 Missing and 1 partial ⚠️
lightning/src/ln/channel.rs	88.88%	8 Missing ⚠️
lightning/src/events/mod.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4490 +/- ##
=======================================
Coverage 86.11% 86.11% =======================================
Files 157 157 Lines 108851 108817 -34 Branches 108851 108817 -34 =======================================
- Hits 93735 93706 -29 + Misses 12503 12494 -9 - Partials 2613 2617 +4 

Flag	Coverage Δ
tests	86.11% <81.60%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[TheBlueMatt]

please add calls to this in the fuzzer.

[wpaulino]

I'll look into adding this when I restore splicing in the fuzzer

[TheBlueMatt]

Does this suffice? We call reset_pending_splice_state which asserts that !has_received_commitment_signed() but we don't check it here?

[wpaulino]

We can only process the counterparty's initial commitment_signed once the user calls back with ChannelManager::funding_transaction_signed.

[ldk-reviews-bot]

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[jkczyz]

CI is unhappy. One of my PRs added a parameter to one of the test helpers. So probably need a rebase.

[TheBlueMatt]

Needs rebase now

[TheBlueMatt]

This really feels like it should be coming from the channel in the InteractiveTxMsgError, not set randomly here.

[wpaulino]

A user may wish to cancel an in-flight funding negotiation for whatever reason (e.g., mempool feerates have gone down, inability to sign, etc.), so we should make it possible for them to do so. Note that this can only be done for splice funding negotiations for which the user has made a contribution to.

[ldk-reviews-bot]

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[ldk-claude-review-bot]

This .expect() can panic in release builds. While cancel_splice in channel.rs verifies made_contribution is true, the maybe_create_splice_funding_failed! macro additionally subtracts contributions that overlap with prior RBF rounds (via prior_contributed_inputs/outputs). For a non-initiator who reuses the same UTXOs across RBF attempts with no explicit output contributions, the subtraction can empty the lists, causing the macro to return None (line 6740-6742 of channel.rs: if !is_initiator && contributed_inputs.is_empty() && contributed_outputs.is_empty() { return None; }).

The debug_assert!(splice_funding_failed.is_some()) at channel.rs:12323 catches this in debug, but this expect will crash in release for that edge case. Consider handling None gracefully, e.g. by returning an APIError or skipping the events.

[wpaulino]

@jkczyz looks like that if statement it's referring to is indeed happening after the filtering. We should check whether the contribution is empty prior to filtering. I also noticed that we'll always emit DiscardFunding even when both contributed inputs and outputs are empty, we should only do so when there is actually something to discard.

[jkczyz]

@jkczyz looks like that if statement it's referring to is indeed happening after the filtering. We should check whether the contribution is empty prior to filtering.

Hmm... we may want to base this on #4514. It refactors that code a bit and removes maybe_create_splice_funding_failed!. I believe the new splice_funding_failed_for! macro does it correctly now (dc0609d)

I also noticed that we'll always emit DiscardFunding even when both contributed inputs and outputs are empty, we should only do so when there is actually something to discard.

I believe that is fixed in #4514, too. Can't recall if it's the same commit, but the PR should consolidate the filtering logic to FundingContribution::into_unique_contributions.

[ldk-claude-review-bot]

I've completed a thorough review of the entire PR diff, examining every hunk and cross-referencing with the codebase. All prior review comments have been verified against the current code.

Two prior comments appear to be resolved in the current code:

• events/mod.rs:193 — Display string is now correctly "splice locally canceled"
• interactivetxs.rs:142 — Doc link now resolves correctly

Review Summary

No new issues found beyond those flagged in the prior review pass. The remaining prior findings that are still applicable:

1. lightning/src/ln/channelmanager.rs:4942 — debug_assert!(splice_funding_failed.is_some()) / potential release-mode silent event loss for non-initiator RBF edge case where splice_funding_failed_for! macro filters all contributions to None.
2. lightning/src/ln/channel.rs:12830 — has_local_contribution() vs contributed_inputs()/contributed_outputs() use different computation paths for the same semantic check across FundingNegotiation variants.
3. lightning/src/ln/channelmanager.rs:4941 — PersistenceNotifierGuard::manually_notify does not set needs_persist_flag. While the explicit event_persist_notifier.notify() at line 4978 ensures prompt event delivery, channel state changes (splice reset, quiescence exit) won't be persisted until an unrelated trigger. If the node crashes before then, the cancel is lost and the splice may resume on reconnection.
4. lightning/src/ln/splicing_tests.rs:3140 — if state == 0 is unreachable dead code since that case returns early at line 3152.

Verification notes

• The counterparty_aborted → allow_resumption boolean inversion is correct across all 9 call sites (verified each one).
• Lock ordering in cancel_funding_contributed is correct — peer/channel locks dropped before handle_interactive_tx_msg_err/handle_error.
• The debug_assert!(self.should_reset_pending_splice_state(false)) in reset_pending_splice_state holds for the cancel_funding_contributed path because: has_holder_tx_signatures()=false implies has_received_commitment_signed()=false (counterparty's commitment_signed is stashed until funding_transaction_signed is called).
• The quiescent_action cancellation path correctly handles three sub-cases: stfu not yet sent (Ignore), stfu sent but not received (WarnAndDisconnect), and both stfus exchanged (Ignore — counterparty's splice continues unaffected).
• No TOCTOU risk between the has_holder_tx_signatures() check and reset_pending_splice_state since both run under the peer_state lock.
• TLV tag 11 is reused for LocallyCanceled (renamed from LocallyAbandoned), maintaining wire compatibility.

[jkczyz]

Do we need to worry about updating PendingFunding::contributions when reseting? This may be a pre-existing issue, though.

[wpaulino]

Already fixed in a547960.

[ldk-reviews-bot]

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 2nd Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 3rd Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 4th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 5th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 6th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-claude-review-bot]

The previous abandon_splice used PersistenceNotifierGuard::optionally_notify and returned NotifyOption::SkipPersistHandleEvents on success, which would wake up the background processor to deliver the newly-added SpliceFailed/DiscardFunding events and the tx_abort message promptly.

manually_notify delegates the notification decision to process_background_events(), which returns SkipPersistNoEvents when there are no pending background events. This means when no holding-cell HTLCs are freed (the handle_holding_cell_free_result path that calls notify()), the background processor is never woken up. Events and messages sit in memory until the next polling interval or until some unrelated activity triggers notification.

This is also a persistence concern: the splice state reset and quiescence exit modify channel state, but without notification, persistence may not happen until the next trigger. If the node crashes in between, the cancel is effectively lost (though the reestablishment protocol handles recovery).

Consider using optionally_notify (returning SkipPersistHandleEvents on success, SkipPersistNoEvents on error) to match the behavior of other public APIs like funding_contributed and funding_transaction_signed.

[ldk-claude-review-bot]

Dead code: state == 0 can never be true here because that case returned early at line 2990. The if branch is unreachable — only the else ever runs.

Suggested change

	acceptor.node.handle_tx_abort(node_id_initiator, tx_abort);
	if state == 0{
	assert!(acceptor.node.get_and_clear_pending_msg_events().is_empty());
	acceptor.node.handle_tx_abort(node_id_initiator, tx_abort);
	{
	let tx_abort = get_event_msg!(acceptor,MessageSendEvent::SendTxAbort, node_id_initiator);

[codecov]

Codecov Report

❌ Patch coverage is 81.60000% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.11%. Comparing base (c766417) to head (637cc41).
⚠️ Report is 17 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	72.54%	13 Missing and 1 partial ⚠️
lightning/src/ln/channel.rs	88.88%	8 Missing ⚠️
lightning/src/events/mod.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4490 +/- ##
=======================================
Coverage 86.11% 86.11% =======================================
Files 157 157 Lines 108851 108817 -34 Branches 108851 108817 -34 =======================================
- Hits 93735 93706 -29 + Misses 12503 12494 -9 - Partials 2613 2617 +4 

Flag	Coverage Δ
tests	86.11% <81.60%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[TheBlueMatt]

please add calls to this in the fuzzer.

[wpaulino]

I'll look into adding this when I restore splicing in the fuzzer

[TheBlueMatt]

Does this suffice? We call reset_pending_splice_state which asserts that !has_received_commitment_signed() but we don't check it here?

[wpaulino]

We can only process the counterparty's initial commitment_signed once the user calls back with ChannelManager::funding_transaction_signed.

[ldk-reviews-bot]

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[jkczyz]

CI is unhappy. One of my PRs added a parameter to one of the test helpers. So probably need a rebase.

[TheBlueMatt]

Needs rebase now

[TheBlueMatt]

This really feels like it should be coming from the channel in the InteractiveTxMsgError, not set randomly here.

[wpaulino]

A user may wish to cancel an in-flight funding negotiation for whatever reason (e.g., mempool feerates have gone down, inability to sign, etc.), so we should make it possible for them to do so. Note that this can only be done for splice funding negotiations for which the user has made a contribution to.

[ldk-reviews-bot]

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[ldk-claude-review-bot]

This .expect() can panic in release builds. While cancel_splice in channel.rs verifies made_contribution is true, the maybe_create_splice_funding_failed! macro additionally subtracts contributions that overlap with prior RBF rounds (via prior_contributed_inputs/outputs). For a non-initiator who reuses the same UTXOs across RBF attempts with no explicit output contributions, the subtraction can empty the lists, causing the macro to return None (line 6740-6742 of channel.rs: if !is_initiator && contributed_inputs.is_empty() && contributed_outputs.is_empty() { return None; }).

The debug_assert!(splice_funding_failed.is_some()) at channel.rs:12323 catches this in debug, but this expect will crash in release for that edge case. Consider handling None gracefully, e.g. by returning an APIError or skipping the events.

[wpaulino]

@jkczyz looks like that if statement it's referring to is indeed happening after the filtering. We should check whether the contribution is empty prior to filtering. I also noticed that we'll always emit DiscardFunding even when both contributed inputs and outputs are empty, we should only do so when there is actually something to discard.

[jkczyz]

@jkczyz looks like that if statement it's referring to is indeed happening after the filtering. We should check whether the contribution is empty prior to filtering.

Hmm... we may want to base this on #4514. It refactors that code a bit and removes maybe_create_splice_funding_failed!. I believe the new splice_funding_failed_for! macro does it correctly now (dc0609d)

I also noticed that we'll always emit DiscardFunding even when both contributed inputs and outputs are empty, we should only do so when there is actually something to discard.

I believe that is fixed in #4514, too. Can't recall if it's the same commit, but the PR should consolidate the filtering logic to FundingContribution::into_unique_contributions.

[ldk-claude-review-bot]

I've completed a thorough review of the entire PR diff, examining every hunk and cross-referencing with the codebase. All prior review comments have been verified against the current code.

Two prior comments appear to be resolved in the current code:

• events/mod.rs:193 — Display string is now correctly "splice locally canceled"
• interactivetxs.rs:142 — Doc link now resolves correctly

Review Summary

No new issues found beyond those flagged in the prior review pass. The remaining prior findings that are still applicable:

1. lightning/src/ln/channelmanager.rs:4942 — debug_assert!(splice_funding_failed.is_some()) / potential release-mode silent event loss for non-initiator RBF edge case where splice_funding_failed_for! macro filters all contributions to None.
2. lightning/src/ln/channel.rs:12830 — has_local_contribution() vs contributed_inputs()/contributed_outputs() use different computation paths for the same semantic check across FundingNegotiation variants.
3. lightning/src/ln/channelmanager.rs:4941 — PersistenceNotifierGuard::manually_notify does not set needs_persist_flag. While the explicit event_persist_notifier.notify() at line 4978 ensures prompt event delivery, channel state changes (splice reset, quiescence exit) won't be persisted until an unrelated trigger. If the node crashes before then, the cancel is lost and the splice may resume on reconnection.
4. lightning/src/ln/splicing_tests.rs:3140 — if state == 0 is unreachable dead code since that case returns early at line 3152.

Verification notes

• The counterparty_aborted → allow_resumption boolean inversion is correct across all 9 call sites (verified each one).
• Lock ordering in cancel_funding_contributed is correct — peer/channel locks dropped before handle_interactive_tx_msg_err/handle_error.
• The debug_assert!(self.should_reset_pending_splice_state(false)) in reset_pending_splice_state holds for the cancel_funding_contributed path because: has_holder_tx_signatures()=false implies has_received_commitment_signed()=false (counterparty's commitment_signed is stashed until funding_transaction_signed is called).
• The quiescent_action cancellation path correctly handles three sub-cases: stfu not yet sent (Ignore), stfu sent but not received (WarnAndDisconnect), and both stfus exchanged (Ignore — counterparty's splice continues unaffected).
• No TOCTOU risk between the has_holder_tx_signatures() check and reset_pending_splice_state since both run under the peer_state lock.
• TLV tag 11 is reused for LocallyCanceled (renamed from LocallyAbandoned), maintaining wire compatibility.

[jkczyz]

Do we need to worry about updating PendingFunding::contributions when reseting? This may be a pre-existing issue, though.

[wpaulino]

Already fixed in a547960.

[ldk-reviews-bot]

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 2nd Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 3rd Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 4th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 5th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 6th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-claude-review-bot]

The previous abandon_splice used PersistenceNotifierGuard::optionally_notify and returned NotifyOption::SkipPersistHandleEvents on success, which would wake up the background processor to deliver the newly-added SpliceFailed/DiscardFunding events and the tx_abort message promptly.

manually_notify delegates the notification decision to process_background_events(), which returns SkipPersistNoEvents when there are no pending background events. This means when no holding-cell HTLCs are freed (the handle_holding_cell_free_result path that calls notify()), the background processor is never woken up. Events and messages sit in memory until the next polling interval or until some unrelated activity triggers notification.

This is also a persistence concern: the splice state reset and quiescence exit modify channel state, but without notification, persistence may not happen until the next trigger. If the node crashes in between, the cancel is effectively lost (though the reestablishment protocol handles recovery).

Consider using optionally_notify (returning SkipPersistHandleEvents on success, SkipPersistNoEvents on error) to match the behavior of other public APIs like funding_contributed and funding_transaction_signed.

[ldk-claude-review-bot]

Dead code: state == 0 can never be true here because that case returned early at line 2990. The if branch is unreachable — only the else ever runs.

Suggested change

	acceptor.node.handle_tx_abort(node_id_initiator, tx_abort);
	if state == 0{
	assert!(acceptor.node.get_and_clear_pending_msg_events().is_empty());
	acceptor.node.handle_tx_abort(node_id_initiator, tx_abort);
	{
	let tx_abort = get_event_msg!(acceptor,MessageSendEvent::SendTxAbort, node_id_initiator);

[codecov]

Codecov Report

❌ Patch coverage is 81.60000% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.11%. Comparing base (c766417) to head (637cc41).
⚠️ Report is 17 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	72.54%	13 Missing and 1 partial ⚠️
lightning/src/ln/channel.rs	88.88%	8 Missing ⚠️
lightning/src/events/mod.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4490 +/- ##
=======================================
Coverage 86.11% 86.11% =======================================
Files 157 157 Lines 108851 108817 -34 Branches 108851 108817 -34 =======================================
- Hits 93735 93706 -29 + Misses 12503 12494 -9 - Partials 2613 2617 +4 

Flag	Coverage Δ
tests	86.11% <81.60%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[TheBlueMatt]

please add calls to this in the fuzzer.

[wpaulino]

I'll look into adding this when I restore splicing in the fuzzer

[TheBlueMatt]

Does this suffice? We call reset_pending_splice_state which asserts that !has_received_commitment_signed() but we don't check it here?

[wpaulino]

We can only process the counterparty's initial commitment_signed once the user calls back with ChannelManager::funding_transaction_signed.

[ldk-reviews-bot]

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[jkczyz]

CI is unhappy. One of my PRs added a parameter to one of the test helpers. So probably need a rebase.

[TheBlueMatt]

Needs rebase now

[TheBlueMatt]

This really feels like it should be coming from the channel in the InteractiveTxMsgError, not set randomly here.

[wpaulino]

A user may wish to cancel an in-flight funding negotiation for whatever reason (e.g., mempool feerates have gone down, inability to sign, etc.), so we should make it possible for them to do so. Note that this can only be done for splice funding negotiations for which the user has made a contribution to.

[ldk-reviews-bot]

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[ldk-claude-review-bot]

This .expect() can panic in release builds. While cancel_splice in channel.rs verifies made_contribution is true, the maybe_create_splice_funding_failed! macro additionally subtracts contributions that overlap with prior RBF rounds (via prior_contributed_inputs/outputs). For a non-initiator who reuses the same UTXOs across RBF attempts with no explicit output contributions, the subtraction can empty the lists, causing the macro to return None (line 6740-6742 of channel.rs: if !is_initiator && contributed_inputs.is_empty() && contributed_outputs.is_empty() { return None; }).

The debug_assert!(splice_funding_failed.is_some()) at channel.rs:12323 catches this in debug, but this expect will crash in release for that edge case. Consider handling None gracefully, e.g. by returning an APIError or skipping the events.

[wpaulino]

@jkczyz looks like that if statement it's referring to is indeed happening after the filtering. We should check whether the contribution is empty prior to filtering. I also noticed that we'll always emit DiscardFunding even when both contributed inputs and outputs are empty, we should only do so when there is actually something to discard.

[jkczyz]

@jkczyz looks like that if statement it's referring to is indeed happening after the filtering. We should check whether the contribution is empty prior to filtering.

Hmm... we may want to base this on #4514. It refactors that code a bit and removes maybe_create_splice_funding_failed!. I believe the new splice_funding_failed_for! macro does it correctly now (dc0609d)

I also noticed that we'll always emit DiscardFunding even when both contributed inputs and outputs are empty, we should only do so when there is actually something to discard.

I believe that is fixed in #4514, too. Can't recall if it's the same commit, but the PR should consolidate the filtering logic to FundingContribution::into_unique_contributions.

[ldk-claude-review-bot]

I've completed a thorough review of the entire PR diff, examining every hunk and cross-referencing with the codebase. All prior review comments have been verified against the current code.

Two prior comments appear to be resolved in the current code:

• events/mod.rs:193 — Display string is now correctly "splice locally canceled"
• interactivetxs.rs:142 — Doc link now resolves correctly

Review Summary

No new issues found beyond those flagged in the prior review pass. The remaining prior findings that are still applicable:

1. lightning/src/ln/channelmanager.rs:4942 — debug_assert!(splice_funding_failed.is_some()) / potential release-mode silent event loss for non-initiator RBF edge case where splice_funding_failed_for! macro filters all contributions to None.
2. lightning/src/ln/channel.rs:12830 — has_local_contribution() vs contributed_inputs()/contributed_outputs() use different computation paths for the same semantic check across FundingNegotiation variants.
3. lightning/src/ln/channelmanager.rs:4941 — PersistenceNotifierGuard::manually_notify does not set needs_persist_flag. While the explicit event_persist_notifier.notify() at line 4978 ensures prompt event delivery, channel state changes (splice reset, quiescence exit) won't be persisted until an unrelated trigger. If the node crashes before then, the cancel is lost and the splice may resume on reconnection.
4. lightning/src/ln/splicing_tests.rs:3140 — if state == 0 is unreachable dead code since that case returns early at line 3152.

Verification notes

• The counterparty_aborted → allow_resumption boolean inversion is correct across all 9 call sites (verified each one).
• Lock ordering in cancel_funding_contributed is correct — peer/channel locks dropped before handle_interactive_tx_msg_err/handle_error.
• The debug_assert!(self.should_reset_pending_splice_state(false)) in reset_pending_splice_state holds for the cancel_funding_contributed path because: has_holder_tx_signatures()=false implies has_received_commitment_signed()=false (counterparty's commitment_signed is stashed until funding_transaction_signed is called).
• The quiescent_action cancellation path correctly handles three sub-cases: stfu not yet sent (Ignore), stfu sent but not received (WarnAndDisconnect), and both stfus exchanged (Ignore — counterparty's splice continues unaffected).
• No TOCTOU risk between the has_holder_tx_signatures() check and reset_pending_splice_state since both run under the peer_state lock.
• TLV tag 11 is reused for LocallyCanceled (renamed from LocallyAbandoned), maintaining wire compatibility.

[jkczyz]

Do we need to worry about updating PendingFunding::contributions when reseting? This may be a pre-existing issue, though.

[wpaulino]

Already fixed in a547960.

[ldk-reviews-bot]

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 2nd Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 3rd Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 4th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 5th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 6th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-claude-review-bot]

The previous abandon_splice used PersistenceNotifierGuard::optionally_notify and returned NotifyOption::SkipPersistHandleEvents on success, which would wake up the background processor to deliver the newly-added SpliceFailed/DiscardFunding events and the tx_abort message promptly.

manually_notify delegates the notification decision to process_background_events(), which returns SkipPersistNoEvents when there are no pending background events. This means when no holding-cell HTLCs are freed (the handle_holding_cell_free_result path that calls notify()), the background processor is never woken up. Events and messages sit in memory until the next polling interval or until some unrelated activity triggers notification.

This is also a persistence concern: the splice state reset and quiescence exit modify channel state, but without notification, persistence may not happen until the next trigger. If the node crashes in between, the cancel is effectively lost (though the reestablishment protocol handles recovery).

Consider using optionally_notify (returning SkipPersistHandleEvents on success, SkipPersistNoEvents on error) to match the behavior of other public APIs like funding_contributed and funding_transaction_signed.

[ldk-claude-review-bot]

Dead code: state == 0 can never be true here because that case returned early at line 2990. The if branch is unreachable — only the else ever runs.

Suggested change

	acceptor.node.handle_tx_abort(node_id_initiator, tx_abort);
	if state == 0{
	assert!(acceptor.node.get_and_clear_pending_msg_events().is_empty());
	acceptor.node.handle_tx_abort(node_id_initiator, tx_abort);
	{
	let tx_abort = get_event_msg!(acceptor,MessageSendEvent::SendTxAbort, node_id_initiator);

[codecov]

Codecov Report

❌ Patch coverage is 81.60000% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.11%. Comparing base (c766417) to head (637cc41).
⚠️ Report is 17 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	72.54%	13 Missing and 1 partial ⚠️
lightning/src/ln/channel.rs	88.88%	8 Missing ⚠️
lightning/src/events/mod.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4490 +/- ##
=======================================
Coverage 86.11% 86.11% =======================================
Files 157 157 Lines 108851 108817 -34 Branches 108851 108817 -34 =======================================
- Hits 93735 93706 -29 + Misses 12503 12494 -9 - Partials 2613 2617 +4 

Flag	Coverage Δ
tests	86.11% <81.60%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[TheBlueMatt]

please add calls to this in the fuzzer.

[wpaulino]

I'll look into adding this when I restore splicing in the fuzzer

[TheBlueMatt]

Does this suffice? We call reset_pending_splice_state which asserts that !has_received_commitment_signed() but we don't check it here?

[wpaulino]

We can only process the counterparty's initial commitment_signed once the user calls back with ChannelManager::funding_transaction_signed.

[ldk-reviews-bot]

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[jkczyz]

CI is unhappy. One of my PRs added a parameter to one of the test helpers. So probably need a rebase.

[TheBlueMatt]

Needs rebase now

[TheBlueMatt]

This really feels like it should be coming from the channel in the InteractiveTxMsgError, not set randomly here.

[wpaulino]

A user may wish to cancel an in-flight funding negotiation for whatever reason (e.g., mempool feerates have gone down, inability to sign, etc.), so we should make it possible for them to do so. Note that this can only be done for splice funding negotiations for which the user has made a contribution to.

[ldk-reviews-bot]

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[ldk-claude-review-bot]

This .expect() can panic in release builds. While cancel_splice in channel.rs verifies made_contribution is true, the maybe_create_splice_funding_failed! macro additionally subtracts contributions that overlap with prior RBF rounds (via prior_contributed_inputs/outputs). For a non-initiator who reuses the same UTXOs across RBF attempts with no explicit output contributions, the subtraction can empty the lists, causing the macro to return None (line 6740-6742 of channel.rs: if !is_initiator && contributed_inputs.is_empty() && contributed_outputs.is_empty() { return None; }).

The debug_assert!(splice_funding_failed.is_some()) at channel.rs:12323 catches this in debug, but this expect will crash in release for that edge case. Consider handling None gracefully, e.g. by returning an APIError or skipping the events.

[wpaulino]

@jkczyz looks like that if statement it's referring to is indeed happening after the filtering. We should check whether the contribution is empty prior to filtering. I also noticed that we'll always emit DiscardFunding even when both contributed inputs and outputs are empty, we should only do so when there is actually something to discard.

[jkczyz]

@jkczyz looks like that if statement it's referring to is indeed happening after the filtering. We should check whether the contribution is empty prior to filtering.

Hmm... we may want to base this on #4514. It refactors that code a bit and removes maybe_create_splice_funding_failed!. I believe the new splice_funding_failed_for! macro does it correctly now (dc0609d)

I also noticed that we'll always emit DiscardFunding even when both contributed inputs and outputs are empty, we should only do so when there is actually something to discard.

I believe that is fixed in #4514, too. Can't recall if it's the same commit, but the PR should consolidate the filtering logic to FundingContribution::into_unique_contributions.

[ldk-claude-review-bot]

I've completed a thorough review of the entire PR diff, examining every hunk and cross-referencing with the codebase. All prior review comments have been verified against the current code.

Two prior comments appear to be resolved in the current code:

• events/mod.rs:193 — Display string is now correctly "splice locally canceled"
• interactivetxs.rs:142 — Doc link now resolves correctly

Review Summary

No new issues found beyond those flagged in the prior review pass. The remaining prior findings that are still applicable:

1. lightning/src/ln/channelmanager.rs:4942 — debug_assert!(splice_funding_failed.is_some()) / potential release-mode silent event loss for non-initiator RBF edge case where splice_funding_failed_for! macro filters all contributions to None.
2. lightning/src/ln/channel.rs:12830 — has_local_contribution() vs contributed_inputs()/contributed_outputs() use different computation paths for the same semantic check across FundingNegotiation variants.
3. lightning/src/ln/channelmanager.rs:4941 — PersistenceNotifierGuard::manually_notify does not set needs_persist_flag. While the explicit event_persist_notifier.notify() at line 4978 ensures prompt event delivery, channel state changes (splice reset, quiescence exit) won't be persisted until an unrelated trigger. If the node crashes before then, the cancel is lost and the splice may resume on reconnection.
4. lightning/src/ln/splicing_tests.rs:3140 — if state == 0 is unreachable dead code since that case returns early at line 3152.

Verification notes

• The counterparty_aborted → allow_resumption boolean inversion is correct across all 9 call sites (verified each one).
• Lock ordering in cancel_funding_contributed is correct — peer/channel locks dropped before handle_interactive_tx_msg_err/handle_error.
• The debug_assert!(self.should_reset_pending_splice_state(false)) in reset_pending_splice_state holds for the cancel_funding_contributed path because: has_holder_tx_signatures()=false implies has_received_commitment_signed()=false (counterparty's commitment_signed is stashed until funding_transaction_signed is called).
• The quiescent_action cancellation path correctly handles three sub-cases: stfu not yet sent (Ignore), stfu sent but not received (WarnAndDisconnect), and both stfus exchanged (Ignore — counterparty's splice continues unaffected).
• No TOCTOU risk between the has_holder_tx_signatures() check and reset_pending_splice_state since both run under the peer_state lock.
• TLV tag 11 is reused for LocallyCanceled (renamed from LocallyAbandoned), maintaining wire compatibility.

[jkczyz]

Do we need to worry about updating PendingFunding::contributions when reseting? This may be a pre-existing issue, though.

[wpaulino]

Already fixed in a547960.

[ldk-reviews-bot]

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 2nd Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 3rd Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 4th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 5th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 6th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-claude-review-bot]

The previous abandon_splice used PersistenceNotifierGuard::optionally_notify and returned NotifyOption::SkipPersistHandleEvents on success, which would wake up the background processor to deliver the newly-added SpliceFailed/DiscardFunding events and the tx_abort message promptly.

manually_notify delegates the notification decision to process_background_events(), which returns SkipPersistNoEvents when there are no pending background events. This means when no holding-cell HTLCs are freed (the handle_holding_cell_free_result path that calls notify()), the background processor is never woken up. Events and messages sit in memory until the next polling interval or until some unrelated activity triggers notification.

This is also a persistence concern: the splice state reset and quiescence exit modify channel state, but without notification, persistence may not happen until the next trigger. If the node crashes in between, the cancel is effectively lost (though the reestablishment protocol handles recovery).

Consider using optionally_notify (returning SkipPersistHandleEvents on success, SkipPersistNoEvents on error) to match the behavior of other public APIs like funding_contributed and funding_transaction_signed.

[ldk-claude-review-bot]

Dead code: state == 0 can never be true here because that case returned early at line 2990. The if branch is unreachable — only the else ever runs.

Suggested change

	acceptor.node.handle_tx_abort(node_id_initiator, tx_abort);
	if state == 0{
	assert!(acceptor.node.get_and_clear_pending_msg_events().is_empty());
	acceptor.node.handle_tx_abort(node_id_initiator, tx_abort);
	{
	let tx_abort = get_event_msg!(acceptor,MessageSendEvent::SendTxAbort, node_id_initiator);

[codecov]

Codecov Report

❌ Patch coverage is 81.60000% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.11%. Comparing base (c766417) to head (637cc41).
⚠️ Report is 17 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	72.54%	13 Missing and 1 partial ⚠️
lightning/src/ln/channel.rs	88.88%	8 Missing ⚠️
lightning/src/events/mod.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4490 +/- ##
=======================================
Coverage 86.11% 86.11% =======================================
Files 157 157 Lines 108851 108817 -34 Branches 108851 108817 -34 =======================================
- Hits 93735 93706 -29 + Misses 12503 12494 -9 - Partials 2613 2617 +4 

Flag	Coverage Δ
tests	86.11% <81.60%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[TheBlueMatt]

please add calls to this in the fuzzer.

[wpaulino]

I'll look into adding this when I restore splicing in the fuzzer

[TheBlueMatt]

Does this suffice? We call reset_pending_splice_state which asserts that !has_received_commitment_signed() but we don't check it here?

[wpaulino]

We can only process the counterparty's initial commitment_signed once the user calls back with ChannelManager::funding_transaction_signed.

[ldk-reviews-bot]

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[jkczyz]

CI is unhappy. One of my PRs added a parameter to one of the test helpers. So probably need a rebase.

[TheBlueMatt]

Needs rebase now

[TheBlueMatt]

This really feels like it should be coming from the channel in the InteractiveTxMsgError, not set randomly here.

[wpaulino]

A user may wish to cancel an in-flight funding negotiation for whatever reason (e.g., mempool feerates have gone down, inability to sign, etc.), so we should make it possible for them to do so. Note that this can only be done for splice funding negotiations for which the user has made a contribution to.

[ldk-reviews-bot]

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[ldk-claude-review-bot]

This .expect() can panic in release builds. While cancel_splice in channel.rs verifies made_contribution is true, the maybe_create_splice_funding_failed! macro additionally subtracts contributions that overlap with prior RBF rounds (via prior_contributed_inputs/outputs). For a non-initiator who reuses the same UTXOs across RBF attempts with no explicit output contributions, the subtraction can empty the lists, causing the macro to return None (line 6740-6742 of channel.rs: if !is_initiator && contributed_inputs.is_empty() && contributed_outputs.is_empty() { return None; }).

The debug_assert!(splice_funding_failed.is_some()) at channel.rs:12323 catches this in debug, but this expect will crash in release for that edge case. Consider handling None gracefully, e.g. by returning an APIError or skipping the events.

[wpaulino]

@jkczyz looks like that if statement it's referring to is indeed happening after the filtering. We should check whether the contribution is empty prior to filtering. I also noticed that we'll always emit DiscardFunding even when both contributed inputs and outputs are empty, we should only do so when there is actually something to discard.

[jkczyz]

@jkczyz looks like that if statement it's referring to is indeed happening after the filtering. We should check whether the contribution is empty prior to filtering.

Hmm... we may want to base this on #4514. It refactors that code a bit and removes maybe_create_splice_funding_failed!. I believe the new splice_funding_failed_for! macro does it correctly now (dc0609d)

I also noticed that we'll always emit DiscardFunding even when both contributed inputs and outputs are empty, we should only do so when there is actually something to discard.

I believe that is fixed in #4514, too. Can't recall if it's the same commit, but the PR should consolidate the filtering logic to FundingContribution::into_unique_contributions.

[ldk-claude-review-bot]

I've completed a thorough review of the entire PR diff, examining every hunk and cross-referencing with the codebase. All prior review comments have been verified against the current code.

Two prior comments appear to be resolved in the current code:

• events/mod.rs:193 — Display string is now correctly "splice locally canceled"
• interactivetxs.rs:142 — Doc link now resolves correctly

Review Summary

No new issues found beyond those flagged in the prior review pass. The remaining prior findings that are still applicable:

1. lightning/src/ln/channelmanager.rs:4942 — debug_assert!(splice_funding_failed.is_some()) / potential release-mode silent event loss for non-initiator RBF edge case where splice_funding_failed_for! macro filters all contributions to None.
2. lightning/src/ln/channel.rs:12830 — has_local_contribution() vs contributed_inputs()/contributed_outputs() use different computation paths for the same semantic check across FundingNegotiation variants.
3. lightning/src/ln/channelmanager.rs:4941 — PersistenceNotifierGuard::manually_notify does not set needs_persist_flag. While the explicit event_persist_notifier.notify() at line 4978 ensures prompt event delivery, channel state changes (splice reset, quiescence exit) won't be persisted until an unrelated trigger. If the node crashes before then, the cancel is lost and the splice may resume on reconnection.
4. lightning/src/ln/splicing_tests.rs:3140 — if state == 0 is unreachable dead code since that case returns early at line 3152.

Verification notes

• The counterparty_aborted → allow_resumption boolean inversion is correct across all 9 call sites (verified each one).
• Lock ordering in cancel_funding_contributed is correct — peer/channel locks dropped before handle_interactive_tx_msg_err/handle_error.
• The debug_assert!(self.should_reset_pending_splice_state(false)) in reset_pending_splice_state holds for the cancel_funding_contributed path because: has_holder_tx_signatures()=false implies has_received_commitment_signed()=false (counterparty's commitment_signed is stashed until funding_transaction_signed is called).
• The quiescent_action cancellation path correctly handles three sub-cases: stfu not yet sent (Ignore), stfu sent but not received (WarnAndDisconnect), and both stfus exchanged (Ignore — counterparty's splice continues unaffected).
• No TOCTOU risk between the has_holder_tx_signatures() check and reset_pending_splice_state since both run under the peer_state lock.
• TLV tag 11 is reused for LocallyCanceled (renamed from LocallyAbandoned), maintaining wire compatibility.

[jkczyz]

Do we need to worry about updating PendingFunding::contributions when reseting? This may be a pre-existing issue, though.

[wpaulino]

Already fixed in a547960.

[ldk-reviews-bot]

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 2nd Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 3rd Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 4th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 5th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 6th Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-claude-review-bot]

The previous abandon_splice used PersistenceNotifierGuard::optionally_notify and returned NotifyOption::SkipPersistHandleEvents on success, which would wake up the background processor to deliver the newly-added SpliceFailed/DiscardFunding events and the tx_abort message promptly.

manually_notify delegates the notification decision to process_background_events(), which returns SkipPersistNoEvents when there are no pending background events. This means when no holding-cell HTLCs are freed (the handle_holding_cell_free_result path that calls notify()), the background processor is never woken up. Events and messages sit in memory until the next polling interval or until some unrelated activity triggers notification.

This is also a persistence concern: the splice state reset and quiescence exit modify channel state, but without notification, persistence may not happen until the next trigger. If the node crashes in between, the cancel is effectively lost (though the reestablishment protocol handles recovery).

Consider using optionally_notify (returning SkipPersistHandleEvents on success, SkipPersistNoEvents on error) to match the behavior of other public APIs like funding_contributed and funding_transaction_signed.

[ldk-claude-review-bot]

Dead code: state == 0 can never be true here because that case returned early at line 2990. The if branch is unreachable — only the else ever runs.

Suggested change

	acceptor.node.handle_tx_abort(node_id_initiator, tx_abort);
	if state == 0{
	assert!(acceptor.node.get_and_clear_pending_msg_events().is_empty());
	acceptor.node.handle_tx_abort(node_id_initiator, tx_abort);
	{
	let tx_abort = get_event_msg!(acceptor,MessageSendEvent::SendTxAbort, node_id_initiator);

[codecov]

Codecov Report

❌ Patch coverage is 81.60000% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.11%. Comparing base (c766417) to head (637cc41).
⚠️ Report is 17 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	72.54%	13 Missing and 1 partial ⚠️
lightning/src/ln/channel.rs	88.88%	8 Missing ⚠️
lightning/src/events/mod.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4490 +/- ##
=======================================
Coverage 86.11% 86.11% =======================================
Files 157 157 Lines 108851 108817 -34 Branches 108851 108817 -34 =======================================
- Hits 93735 93706 -29 + Misses 12503 12494 -9 - Partials 2613 2617 +4 

Flag	Coverage Δ
tests	86.11% <81.60%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[TheBlueMatt]

please add calls to this in the fuzzer.

[wpaulino]

I'll look into adding this when I restore splicing in the fuzzer

[TheBlueMatt]

Does this suffice? We call reset_pending_splice_state which asserts that !has_received_commitment_signed() but we don't check it here?

[wpaulino]

We can only process the counterparty's initial commitment_signed once the user calls back with ChannelManager::funding_transaction_signed.

[ldk-reviews-bot]

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[jkczyz]

CI is unhappy. One of my PRs added a parameter to one of the test helpers. So probably need a rebase.

[TheBlueMatt]

Needs rebase now

[TheBlueMatt]

This really feels like it should be coming from the channel in the InteractiveTxMsgError, not set randomly here.