Fix panic when calling batch_funding_transaction_generated early
#4015
Conversation
TheBlueMatt
commented
Aug 16, 2025
TheBlueMatt
commented
|
👋 Thanks for assigning @tnull as a reviewer! |
|
👋 The first review has been submitted! Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer. |
`functional_tests.rs` is a rather large beast, but with this move we take it down to under 10k LoC.
If a user calls `batch_funding_transaction_generated` before a channel is ready to fund its possible to hit an `unwrap` when the transaction-scanning logic attempts to fetch the channel's expected output `scriptPubKey`. While users shouldn't be doing this, we should also avoid the panic, so here check the channel state first. Found by the `full_stack_target` fuzzer.
When a channel gets replaced before we can fund it, its possible now (due to RNG output repetition) to hit the "trying to fund channel before its ready to be funded" error in the `full_stack_target` fuzzer. Thus, we now simply ignore errors when funding.
TheBlueMatt
force-pushed
the
2025-08-fst-funding
branch
from
c20d733 to
c1fefcf
Compare
|
Rebased. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4015 +/- ##
=======================================
Coverage 88.84% 88.84%
=======================================
Files 175 175
Lines 127723 127762 +39
Branches 127723 127762 +39
=======================================
+ Hits 113472 113516 +44
+ Misses 11686 11679 -7
- Partials 2565 2567 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| @@ -857,21 +857,15 @@ pub fn do_test(mut data: &[u8], logger: &Arc<dyn Logger>) { | |||
| } | |||
| if tx.version.0 <= 0xff && !channels.is_empty() { | |||
| let chans = channels.iter().map(|(a, b)| (a, b)).collect::<Vec<_>>(); | |||
| if let Err(e) = | |||
There was a problem hiding this comment.
Hmm, should we just allow this specific error case, i.e., still fail on other errors? Otherwise this might also relax our checks for other errors which we still might want to catch?
There was a problem hiding this comment.
We could, but I'm not really sure its worth bothering here - matching on error messages sucks, and "spurious failure to fund channel" seems like an issue that is better caught with normal functional tests (I imagine it'll be kinda hard to have a spurious failure here, anyway).
|
Simple enough, landing. |
