Skip to content

Conversation

pm47
Copy link
Member

@pm47 pm47 commented Jun 28, 2023

This guarantees that the peer will never block before processing a channel message, but implies that:

  • updating these values is done outside of the peer (note: instantiating the electrum client is already done outside)
  • the peer cannot be instantiated before a connection to electrum has been established

This guarantees that the peer will never block before processing a
channel message, but implies that:
- updating these values is done outside of the peer
- the peer cannot be instantiated before a connection to electrum has
  been established

init {
launch {
watcher.client.notifications.filterIsInstance<HeaderSubscriptionResponse>()
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was a race condition here between establishing the connection to electrum (which happens outside of the peer), and subscribing to HeaderSubscriptionResponse.

If the connection to electrum is very fast, tje peer will miss the initial HeaderSubscriptionResponse and then have to wait for the next block.

Same race condition applies for feerates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant