Skip to content

Commit 47e5c04

Browse files
committed
Reset persistence_in_flight counter on error in LSPS1/LSPS2
Previously, if any `.await?` in the persist loop returned an error, the `?` would propagate out of `persist()` before reaching the `fetch_sub` at the end of the loop. This left the counter permanently > 0, causing all subsequent `persist()` calls to early-return and effectively disabling persistence for the lifetime of the handler. Fix this by extracting the loop into `do_persist()` and unconditionally resetting the counter via `store(0, Release)` in the outer `persist()` after `do_persist()` returns, regardless of success or failure. Co-Authored-By: HAL 9000
1 parent 4bec6db commit 47e5c04

2 files changed

Lines changed: 20 additions & 4 deletions

File tree

lightning-liquidity/src/lsps1/service.rs

Lines changed: 10 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -145,14 +145,22 @@ where
145145
// TODO: We should eventually persist in parallel, however, when we do, we probably want to
146146
// introduce some batching to upper-bound the number of requests inflight at any given
147147
// time.
148-
let mut did_persist = false;
149148

150149
if self.persistence_in_flight.fetch_add(1, Ordering::AcqRel) > 0 {
151150
// If we're not the first event processor to get here, just return early, the increment
152151
// we just did will be treated as "go around again" at the end.
153-
return Ok(did_persist);
152+
return Ok(false);
154153
}
155154

155+
let res = self.do_persist().await;
156+
debug_assert!(res.is_err() || self.persistence_in_flight.load(Ordering::Acquire) == 0);
157+
self.persistence_in_flight.store(0, Ordering::Release);
158+
res
159+
}
160+
161+
async fn do_persist(&self) -> Result<bool, lightning::io::Error> {
162+
let mut did_persist = false;
163+
156164
loop {
157165
let mut need_remove = Vec::new();
158166
let mut need_persist = Vec::new();

lightning-liquidity/src/lsps2/service.rs

Lines changed: 10 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1786,14 +1786,22 @@ where
17861786
// TODO: We should eventually persist in parallel, however, when we do, we probably want to
17871787
// introduce some batching to upper-bound the number of requests inflight at any given
17881788
// time.
1789-
let mut did_persist = false;
17901789

17911790
if self.persistence_in_flight.fetch_add(1, Ordering::AcqRel) > 0 {
17921791
// If we're not the first event processor to get here, just return early, the increment
17931792
// we just did will be treated as "go around again" at the end.
1794-
return Ok(did_persist);
1793+
return Ok(false);
17951794
}
17961795

1796+
let res = self.do_persist().await;
1797+
debug_assert!(res.is_err() || self.persistence_in_flight.load(Ordering::Acquire) == 0);
1798+
self.persistence_in_flight.store(0, Ordering::Release);
1799+
res
1800+
}
1801+
1802+
async fn do_persist(&self) -> Result<bool, lightning::io::Error> {
1803+
let mut did_persist = false;
1804+
17971805
loop {
17981806
let mut need_remove = Vec::new();
17991807
let mut need_persist = Vec::new();

0 commit comments

Comments
 (0)