Skip to content

Make on-startup monitor replay more robust #2819

Open
@TheBlueMatt

Description

@TheBlueMatt

Currently we require that users wait until after they've loaded their ChannelMonitors into their chain::Watch until they use the ChannelManager at all. This ensures we dont generate monitor updates prior to the monitors being loaded and ready to be updated (and is relied on by the async monitor on-startup replay logic, which will release the replays as soon as any call into the ChannelManager from the user happens). This is somewhat brittle because (a) we don't clearly document this requirement, which we really need to, (b) this only happens in the rare case, not the common case, so our users aren't going to detect it until they're in production. (a) is easy to fix, but (b) will require some API change of some form:

We could either
(1) add a new API call to the ChannelManager to inform it we're done with initial monitor loading, panicing or failing all calls prior to that point,
(2) we could maybe emulate the same with a new MonitorEvent that indicates at least one monitor was loaded, and implicitly call process_pending_monitor_events if we haven't decided that we're done loading.
(3) try to delay all our monitors via the replay pipeline, allowing operation prior to some "we're ready to go" function.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions