Elias Rohrer

Could you provide some more information regarding the context in which you're seeing this? What persistence backend are you using? Are you somehow killing the node during runtime or are...

> Yes it did crash but unfortunately I don't have the logs from that. Is there any way to recover the channel instead of closing it? Unfortunately I don't think...

> We are running our own LDK-based implementation Alright, thanks, transferred the issue to the general `rust-lightning` repository.

Hmm, yeah, event replaying can be tricky. To handle this we probably need to error out when we detect a duplicate intercept SCID there, but to communicate this to the...

> A duplicate event isn't an error, though, its an expected condition. An error there might imply that the dev should return an error in the event handler, which will...

> This adds new onion messages and a new onion message handler for bLIP 32 messages. It also adds a utility which verifies the proofs and turns them into URIs...

I understand that allowing to override `payer_id` is a potentially dangerous API, but wonder if we should/need to keep `payer_id` exposed for inbound payments, e.g., if other implementations choose to...

> * What is `amt_to_forward_msat`, is that what I should use as `push_msat` (its not, but it really reads like it, in fact its not something the user has to...

> I'm quite confused by this. Looking at the `lsps1` module, I only see two references to `u128`, both related to `PeerState::request_to_cid`. However, the only use of `request_to_cid` is in...

> Hmmm... looks like a few different test are failing now. Two of the failures are expected as they test the failure case you just removed 🙂 The ones failing...