Over time, there were multiple instances where we got confused about which event types exactly are persisted under which circumstances.
This can be tricky as we generally add serialization logic for the persisted events, omit them for the ones that aren't persisted, but then there are exceptions to these rules (e.g., we added serialization logic to OnionMessageIntercepted, which however is only used in one place to determine its serialized_length).
Moreover, Event is a public type that users might or might not want persist independently from our concrete ChannelManager restart logic, so leaving whether or not to persist to the serialization logic is odd, to say the least.
We should simplify and stick to a clear API boundary: implement event serialization for all variants but leave whether or not to persist specific variants, how to deal with restarts etc, to ChannelManager.
Over time, there were multiple instances where we got confused about which event types exactly are persisted under which circumstances.
This can be tricky as we generally add serialization logic for the persisted events, omit them for the ones that aren't persisted, but then there are exceptions to these rules (e.g., we added serialization logic to
OnionMessageIntercepted, which however is only used in one place to determine itsserialized_length).Moreover,
Eventis a public type that users might or might not want persist independently from our concreteChannelManagerrestart logic, so leaving whether or not to persist to the serialization logic is odd, to say the least.We should simplify and stick to a clear API boundary: implement event serialization for all variants but leave whether or not to persist specific variants, how to deal with restarts etc, to
ChannelManager.