Uh oh!
There was an error while loading. Please reload this page.
fuzz: add chanmon stuck HTLC invariant - #4601
Conversation
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
The diff is a single, well-placed assertion block. My prior review covered all the substantive analysis. There are no new issues to flag. No issues found. This is a clean, well-placed invariant check in |
joostjager
commented
May 7, 2026
Merge order: #4571 first if no new changes needed there. |
b015492 to
0d735dfComparejoostjager
commented
May 8, 2026
Rebased after merge of #4571 |
Assert that channel HTLC sets are empty after harness quiescence.
0d735df to
f0edabbCompareldk-reviews-bot
commented
May 9, 2026
🔔 1st Reminder Hey @TheBlueMatt! This PR has been waiting for your review. |
ldk-reviews-bot
commented
May 11, 2026
🔔 2nd Reminder Hey @TheBlueMatt! This PR has been waiting for your review. |
TheBlueMatt
left a comment
There was a problem hiding this comment.
presumably needs to wait on the other pr, but lgtm.
ldk-reviews-bot
commented
May 12, 2026
👋 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. |
Indeed, this breaks fuzzing, even though it is already broken for another reason. Will merge right after |
Uh oh!
There was an error while loading. Please reload this page.
This adds a chanmon consistency fuzz invariant that checks for stuck channel HTLCs after the harness has settled all state. The previous corpus signal was indirect, usually showing up as a later capacity assertion failure, so the new invariant makes the oracle point at the actual leftover HTLC state.
The invariant reproduced the stuck-HTLC issue on upstream/main with this corpus entry:
0270801109191109191f1f10b6ffVerified that #4520 fixes the issue.