You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// These are the default values for the subscription. In case there are
// no invoices yet, this will instruct lnd to just send us all updates.
// If there are existing invoices, these indices will be updated to
// reflect the latest known invoices.
addIndex:=uint64(0)
settleIndex:=uint64(0)
log.Debugf("Starting LND challenger")
// Paginate through all existing invoices on startup and add them to our
// cache. We need to keep track of all invoices to ensure tokens are
// valid.
ctx:=l.clientCtx()
indexOffset:=uint64(0)
for {
log.Debugf("Querying invoices from index %d", indexOffset)
invoiceResp, err:=l.client.ListInvoices(
ctx, &lnrpc.ListInvoiceRequest{
IndexOffset: indexOffset,
NumMaxInvoices: uint64(l.batchSize),
},
)
iferr!=nil {
returnerr
}
// If there are no more invoices, stop pagination.
iflen(invoiceResp.Invoices) ==0 {
break
}
If the node is very old, or has a ton of invoices, this can take quite some time, potentially 10 minutes+.
We should modify this logic to allow the service to start up while we continue to load the invoices in the background using a goroutine.
Steps To Completion
Only when we need to actually access the produced invoiceStates map should we block until the map has been fully populated. We'll likely want to create a new concurrent safe wrapper map that's able to signal any waiters once new elements have been added (see the condition variable usage), with the added ability to block while the map is being populated.
With that in place, we'll LndChallenger.VerifyInvoiceStatus shouldn't need to change too much. It already uses the condition variable to be notified when an entry it added to the map. It just needs to be updated to use the new abstractions mentioned above.
As the start up might take some time, we'll want to update this section to account for a longer timeout:
Today on start up, we'll block to read out all the invoices from the backing node (
LndChallenger.Start
):aperture/challenger/lnd.go
Lines 81 to 109 in 9fd44c9
If the node is very old, or has a ton of invoices, this can take quite some time, potentially 10 minutes+.
We should modify this logic to allow the service to start up while we continue to load the invoices in the background using a goroutine.
Steps To Completion
Only when we need to actually access the produced
invoiceStates
map should we block until the map has been fully populated. We'll likely want to create a new concurrent safe wrapper map that's able to signal any waiters once new elements have been added (see the condition variable usage), with the added ability to block while the map is being populated.With that in place, we'll
LndChallenger.VerifyInvoiceStatus
shouldn't need to change too much. It already uses the condition variable to be notified when an entry it added to the map. It just needs to be updated to use the new abstractions mentioned above.As the start up might take some time, we'll want to update this section to account for a longer timeout:
aperture/challenger/lnd.go
Lines 319 to 337 in 9fd44c9
The text was updated successfully, but these errors were encountered: