The test cases in `TestUpdatePaymentState` run in parallel. One of the
parameters is a pointer and the value to the struct it points to gets
modified during the test.
The race condition was introduced in 8d49dfb07e
To test the fix run from the main folder `go test ./routing/. -race`
before this fix and after.
This commit makes retrying enabling channels conditional. We now would
only retry sending the enable request when the `ChanActiveTimeout` is no
greater than 1 min.
This commit adds a retry logic to the channels that failed with
`ErrEnableInactiveChan` when requesting enabling. We now subscribe the
channel events to decide what to do with the failed channels.
Now that we have the new package `lnd/channeldb/models` we can invert the
depenency between `channeldb` and `invoices`.
- Move all the invoice related types and errors to the
`invoices` package.
- Ensure that all the packages dealing with invoices use the types and
interfaces defined in the `invoices` package.
- Implement the InvoiceDB interface (defined in `lnd/invoices`) in
channeldb.
- Add new mock for InterfaceDB.
- `InvoiceRegistery` tests are now in its own subpacakge (they need to
import both invoices & channeldb). This is temporary until we can
decouple them.
Add a new subpackage to `lnd/channeldb` to hold some of the types that
are used in the package itself and in other packages that should not
depend on `channeldb`.
This commit moves the `HeightHintCache` implementation to the
`channeldb` package and inverts the dependency relation between
`chainntnfs` and `channeldb`.
Many packages depend on channeldb for type definitions,
interfaces, etc. `chainntnfs` is an example of that. `chainntnfs`
defines the `SpendHintCache` and `ConfirmHintCache` interfaces but
it also implments them (`HeightHintCache` struct). The implementation
uses logic that should not leak from channeldb (ex: bucket paths).
This makes our code highly coupled + it would not allow us to use any
of these interfaces in a package that is imported by `channeldb`
(circular dependency).
Send another UTXO if this is a neutrino backend. When sweeping anchors,
there are two transactions created, `local_sweep_tx` for sweeping
Alice's anchor on the local commitment, `remote_sweep_tx` for sweeping
her anchor on the remote commitment. Whenever the force close
transaction is published, Alice will always create these two
transactions to sweep her anchor.
On the other hand, when creating the sweep txes, the anchor itself is
not able to cover the fee, so another wallet UTXO is needed. In our
test case, there's a change output that can be used from the above
funding process. And it's used by both sweep txes - when `lnd` happens
to create the `remote_sweep_tx` first, it will receive an error since
its parent tx, the remote commitment, is not known, hence freeing the
change output to be used by `local_sweep_tx`. For neutrino client,
however, it will consider the transaction which sweeps the remote anchor
as an orphan tx, and it will neither send it to the mempool nor return
an error to free the change output. Thus, if the change output is
already used in `remote_sweep_tx`, we won't have UTXO to create
`local_sweep_tx`.
This commit adds the missing check for anchor sweep in test
`revoked_uncooperative_close_retribution_altruist_watchtower`, also
change the mempool check a bit so it's easier to track.
