From d195acc632a85363a283de0d68cb45f420308fa5 Mon Sep 17 00:00:00 2001
From: "Johan T. Halseth" <johanth@gmail.com>
Date: Thu, 12 Sep 2019 14:36:38 +0200
Subject: [PATCH] chainntnfs/neutrino: start concurrent queues prior to
 connection

Similar to what was done for btcd, just to make sure we won't be blocked
on any incoming notifications, start the queues first thing during
startup.
---
 chainntnfs/neutrinonotify/neutrino.go | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/chainntnfs/neutrinonotify/neutrino.go b/chainntnfs/neutrinonotify/neutrino.go
index c7d2e1ad..d06c0996 100644
--- a/chainntnfs/neutrinonotify/neutrino.go
+++ b/chainntnfs/neutrinonotify/neutrino.go
@@ -116,12 +116,20 @@ func (n *NeutrinoNotifier) Start() error {
 		return nil
 	}
 
+	// Start our concurrent queues before starting the rescan, to ensure
+	// onFilteredBlockConnected and onRelavantTx callbacks won't be
+	// blocked.
+	n.chainUpdates.Start()
+	n.txUpdates.Start()
+
 	// First, we'll obtain the latest block height of the p2p node. We'll
 	// start the auto-rescan from this point. Once a caller actually wishes
 	// to register a chain view, the rescan state will be rewound
 	// accordingly.
 	startingPoint, err := n.p2pNode.BestBlock()
 	if err != nil {
+		n.txUpdates.Stop()
+		n.chainUpdates.Stop()
 		return err
 	}
 	n.bestBlock.Hash = &startingPoint.Hash
@@ -160,9 +168,6 @@ func (n *NeutrinoNotifier) Start() error {
 	)
 	n.rescanErr = n.chainView.Start()
 
-	n.chainUpdates.Start()
-	n.txUpdates.Start()
-
 	n.wg.Add(1)
 	go n.notificationDispatcher()