This commit modifies the recently added logic to the ChainNotifier to:
1. Fix the off-by-one confirmation error that was missed due a flaky
test
2. Ensure that partial historical confirmations are properly handled.
The partial hostile confirmation case arises when a transaction already
a non-zero number of confirmations when the notification is registered,
but less than what would trigger the confirmation notification. To fix
this, transaction which have a partial number of confirmation are now
properly inserted into the confHeap, skipping first first phase for
notifications.
Without these checks, “zombie” notification requests that would never
be dispatched could be registered. This would occur if notification
requests were made for events (transaction confirmation and output
spent) that had already been recorded on the blockchain.
This commit adds support for dispatching the same spend notification to
multiple clients. This is now required by the ChainNotiifer interface
documentation and will be needed within the daemon in order to support
some upcoming refactors.
This commit fixes a possible dead lock when dispatching notifications
caused by the circular communication between the notificationDisptcher
thread and the main notification thread within the btcrpcclient.
Rather than potentially blocking for eternity on a blocking send,
notifications are now instantly handled by appending the notification
on an unbounded queue then launching a goroutine to signal the
dispatcher thread that a new item is available within the queue.
This commit adds multi-client support for confirmation notification of
the same transaction. Within the daemon there might be scenarios where
multiple goroutines are waiting for the same transaction to be
confirmed in order to properly fulfill their tasks. Previously if
multiple clients were registered for the same txid confirmation
notification, then only the client who registered last would receive
the notification.
This commit refactors the existing chainntnfns package in order to
allow more easily allow integration into the main system, by allowing
one to gain access to a set of end-to-end tests for a particular
ChainNotifier implementation.
In order to achieve this, the existing set of tests for the only
concrete implementation (`BtcdNoitifer`) have been refactored to test
against all “registered” notifier interfaces registered. This is
achieved by creating the concept of a “driver” for each concrete
`ChainNotifer` implementation. Once a the package of a particular
driver is imported, solely for the side effects, the init() method
automatically registers the driver.
Additionally, the documentation in various areas of the package have
been cleaned up a bit.
