In this commit, we add additional logic to the primary notification
dispatch loop to ensure that we'll never send the same add/settle event
to the same client twice.
Consider the case where as we're sending a client its notification
backlog, a new invoice is settled (index=9). In this case, the database
will be reflected immediately, and the event will also be queued for
notifying later. We'll send out this latest event during the backlog
clear, but then will send it again once we return back to the main loop.
To ensure that this never happens, we'll now record the last index that
we’ve sent to a client to ensure that we no longer are able to send
duplicate notification events.
In this commit, we now ensure that all modifications to the invoice DB
are properly serialized. This ensures that our time series within the
database will be properly coherent. Additionally, within SettleInvoice,
we remove an extra DB call by taking advantage of the new SettleInvoice
method which will return the invoice being settled as well.
In this commit, we re-work the existing invoiceRegistry struct to
support delivering backlog notifications to subscription clients if
needed. Rather than using 1 goroutine per-client per-event, each client
now gains a concurrent notification queue. This queue will then be used
to ensure in-order delivery of all notifications from the
invoiceEventNotifier.
The SubscribeNotifications method now takes two params: addIndex, and
settleIndex. These should be the values of the last add index and settle
index the caller knows of. If specified (not zero), then we'll look up
all the notifications that the caller has missed, and then deliver those
before sending out any new notifications. In order to do this without
losing ordering of events, we've added a new central goroutine which
will ensure that all events are properly serialized.
In this commit, we add two new methods: InvoicesAddedSince and
InvoicesSettledSince. These methods will be used by higher level
sub-systems that implement notifications to deliver any notifications
backlog based on the last add index, and last settle index that the
client knows of.
It's important to note that care has been taken to ensure that this new
API can be used in a backwards compatible manner. If a client specifies
and index of 0 for either of the methods, then no backlog will be sent.
This is due to the fact that current users of the API don't expect any
backlog notifications to be sent. Additionally, the index actually
starts at 1, instead of 0.
In this commit, we add two new indexes to the invoice database: the add
index, and the settle index. These to indexes essentially form a time
series index on top of the existing primary index bucket. Each time an
invoice is added, we'll advance the addIndex seqno, and then create a
mapping from seqNo -> invoiceNum. Each time an invoice is settled, we'll
do the same, but within the settle index.
This change is required in order to allow callers to effectively seek
into the current invoice database in order to obtain notifications for
any invoices they may have missed out on while they were disconnected.
This will allow us to implement robust streaming invoice notifications
within lnd to ensure that clients never miss an event.
In this commit, in order to allow the caller to specify the amount that
was ultimately accepted for an invoice, the SettleInvoice method has
gained a new parameter: amtPaid. SettleInvoice will now populate the
final amount paid in the database upon db commit.
In this commit, we modify the InvoiceDatabase slightly to allow the link
to record what the final payment about for an invoice was. It may be the
case that the invoice actually had no specified value, or that the payer
paid more than necessary. As a result, it's important that our on-disk
records properly reflect this.
To fix this issue, the SettleInvoice method now also accepts the final
amount paid.
Fixes#856.
In this commit, we extend the current SubscribeInvoice streaming RPC
call. We add two new values to the InvoiceSubscription message:
add_index and settle_index. These fields have also been added to the
current Invoice message. Each time a new invoice is added, the add index
will be incremented. Each time a new invoice is settled the settle index
will be incremented. The new field on the InvoiceSubscription message
allow callers to specify the last add index and the last settle index
they know of. With this new addition, callers will now be able to
reliably receive notifications for new received payments.
Care has been taken to ensure that these changes are backwards
compatible. If callers don't specify either of the new fields, then they
won't receive any notification backlog at all.
Fixes#862.
In this commit, we alter the behavior of the regular
short channel id encoding, such that it returns a nil
slice if the decoded number of elements is 0. This is
done so that it matches the behavior of the zlib
decompression, allowing us to test both in using the
same corpus.
Modifies the behavior of the quick test for
MsgQueryShortChanIDs, such that the generated
slice of expected short chan ids is always nil
if no elements are returned. This mimics the
behavior of the zlib decompression, where
elements are appended to the slice, instead of
assigning to preallocated slice.
Makes the helper methods for constructing witness script
hash and to-local outputs. This will allow watchtowers to
import and reuse this logic when sweeping outputs.
In this commit, we update the generateSphinxPacket to use newLogClosure
to delay the spew evaluation until log print time. Before this commit,
even if we weren't on the trace logging level, the spew call would
always be evaluated.
In this commit, we fix a slight regression that happened when the
sendtoroute RPC call was implemented. As a result of the refactoring,
the debughtlc mode silently broke. In this commit, we fix this by
checking against the zero hash, rather than the length of the payment
hash, as since we use a fixed sized byte slice, it will always be zero.
