In this commit, we make sure that all the `wg.Add(1)` calls succeed
before we attempt to wait on the shutdown of all the goroutines. Under
rare scheduling scenarios, if both `Start` and `Disconnect` are called
concurrently, then this internal race error can be hit, causing the
panic to occur.
Fixes https://github.com/lightningnetwork/lnd/issues/7853
This commit provides the scaffolding for using the new sql stores.
The new interfaces, structs and methods are in sync with other projects
like Taproot Assets.
- Transactional Queries: the sqldb package defines the interfaces required
to execute transactional queries to our storage interface.
- Migration Files Embedded: the migration files are embedded into the binary.
- Database Migrations: I kept the use of 'golang-migrate' to ensure our
codebase remains in sync with the other projects, but can be changed.
- Build Flags for Conditional DB Target: flexibility to specify our database
target at compile-time based on the build flags in the same way we do
with our kv stores.
- Update modules: ran `go mod tidy`.
The MapCustomBroadcastError of the rebroadcaster is defined.
This let's us use the Rebroadcaster of the neutrino package (pushtx)
with other backends and guarantee a consistent behaviour. Prior
to this change the rebroadcaster would stop rebroadcasting
transactions because they did not meet the neutrino specific
broadcastErr type.
Add a test where the channel arbitrator starts up correctly
when a prior unilateral close of a channel did not broadcast
for specific reasons.
Also add a test which ensures that when a crib output is
rejected by the bitcoin backend the startup works correctly
for specific errors.
In case the mempool backend signals that our transaction does not
meet fee requirements when publishing it we will continue to
start up now. The transaction will be rebroadcasted in the
background and a specific log message will be printed to let the
user know that he could increase his mempool size to at least
have this transaction in his own mempool.
For our relatively "static" test invoice, add a simple constructor
using the globals defined, rather than having a global invoice which
risks being mutated.
The goroutine is very long and littered with switches on courierType. By
separating the implementations into different methods for each
courierType we eliminate the cruft and improve readability.
It is very difficult for the fuzzer to create a valid checksum for each
serialized invoice, and we were therefore unable to fuzz deeper than
invoice decoding. We can help the fuzzer generate valid serialized
invoices by calculating and appending the checksum ourselves.
We also switch to using mainnet invoices to make it easier to find valid
invoices for seeding the fuzzer. We prepend the required "lnbc" prefix
ourselves to further help the fuzzer generate valid invoices.
The message signer from invoice_test.go is identical to the one created
in the fuzz test. We're already using the private key from
invoice_test.go, so we may as well use the complete message signer for
simplicity.
The fuzz tests call inv.MinFinalCLTVExpiry() and inv.Expiry() supposedly
to ensure the invoice is well-formed. However, those methods can never
panic or return errors and therefore provide no benefit for this
purpose.
