Uh oh!
There was an error while loading. Please reload this page.
Don't prune pending_requests in persist - #4201
Conversation
Previously, we would also prune any pending `GetInfo` or expired `Buy` requests before we `persist`. This could have lead to races where we drop a pending request and even remove the peer when calling `persist`. Here, we simply split the pruning logic for the `pending_requests` and expired JIT channel state, and only prune the latter before persisting. This generally makes sense, as `pending_requests` isn't currently persisted, so there is no need to prune before repersisting. Both are however still pruned on peer disconnection.
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@## main #4201 +/- ##
=======================================
Coverage 88.86% 88.86% =======================================
Files 180 180 Lines 137910 137913 +3 Branches 137910 137913 +3 =======================================
+ Hits 122547 122560 +13 + Misses 12556 12540 -16 - Partials 2807 2813 +6
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:
|
ldk-reviews-bot
commented
Nov 3, 2025
👋 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. |
Uh oh!
There was an error while loading. Please reload this page.
wvanlint
commented
Nov 3, 2025
All our integration tests succeed now with this change on top of |
TheBlueMatt
commented
Nov 12, 2025
Backported in #4221 |
Previously, we would also prune any pending
GetInfoor expiredBuyrequests before wepersist. This could have lead to races where we drop a pending request and even remove the peer when callingpersist.Here, we simply split the pruning logic for the
pending_requestsand expired JIT channel state, and only prune the latter before persisting. This generally makes sense, aspending_requestsisn't currently persisted, so there is no need to prune before repersisting.Both are however still pruned on peer disconnection.
Thanks @wvanlint for reporting.