Handle remaining panic on persistence failure#498
Conversation
G8XSU
left a comment
There was a problem hiding this comment.
Overall, the diff looks good but not sure if we can mark 381 closed just with this.
tnull
left a comment
There was a problem hiding this comment.
Overall, the diff looks good but not sure if we can mark 381 closed just with this.
Yes, I agree. Generally LGTM (mod some nits), but #381 is about much more that only this case, and unfortunately we're still requiring considerable refactorings upstream on the LDK end before we can resolve all of the panic-on-persistence-failure here.
src/lib.rs
Outdated
| panic!("Couldn't mark event handled due to persistence failure"); | ||
| }); | ||
| pub fn event_handled(&self) -> Result<(), Error> { | ||
| match self.event_queue.event_handled() { |
There was a problem hiding this comment.
nit: Given this just returns the same error, replacing the unwrap_or_else with map_err instead of making this a match might be cleaner here.
tests/common/mod.rs
Outdated
| ref e @ Event::$event_type { .. } => { | ||
| println!("{} got event {:?}", $node.node_id(), e); | ||
| $node.event_handled(); | ||
| assert!($node.event_handled().is_ok()); |
There was a problem hiding this comment.
nit: Let's just use unwrap or expect everywhere instead of assert!(..is_ok())?
e73d808 to
4d8accf
Compare
4d8accf to
171a358
Compare
|
ok sorry about that and thank you for the clarification. Pushed other changes addressing comments from review |
This is the only other
panic!I could find related to a persistence failure. Could've used?there to return theErrbut left the match to maintain thelog_error!message.There were other
panic!s during event handling such as this one:ldk-node/src/event.rs
Lines 542 to 555 in f0338d1