Elias Rohrer
Elias Rohrer
> Why not just run the payjoin protocol after `accept_channel` but before `funding_generated`/signing? Yes, this was also my first question. To quote myself from a previous conversation, where I had...
Rebased and included a fixup to introduce `ReplayEvent` unit struct error variant. But still ironing out some details regarding the approach. > Further, I think we should set the wakeup...
> The event_persist_notifier flag. I'm confused: wouldn't this only work for `ChannelManager`'s event handler, not the others, i.e., `ChainMonitor`, `OnionMessenger`? > I think that's okay if the BP loop busy-waits?...
Rebased to resolve conflicts after #3060 landed, have yet to adjust `MultiFuturePoller` though.
Now added logic to retain failed events in the `OnionMessenger` event queues to have them replayed upon next invocation. To do this I adjusted `MultiFuturePoller` to collect and return the...
> Ah, indeed, you're right. We should, however, add something similar in `chainmonitor`. Agreed. Now added a fixup that has `ChainMonitor` trigger its `event_notifier` when any of the `ChannelMonitor::process_pending_events` calls...
Added a simple BackgroundProcessor test to check events are being replayed and also added a commit documenting the failure-to-handle/persistence behavior of all event variants (i.e., addressed #2097). I now also...
Addressed the feedback.
Rebased on main to resolve minor conflicts after #3138 landed. Let me know if I can squash the fixups.
> LGTM. Feel free to squash, IMO. Squashed without further changes.