This commit adds the FundingManagerPersistence test to ensure that the
funding process completes as expected when nodes shutdown after the the
funding transaction has been broadcast. Note that the final parts of
several wallet tests have been removed, as functionality has been moved
to the Funding Manager and should now be tested there.
Once a channel funding process has advanced to the point of broadcasting
the funding transaction, the state of the channel should be persisted
so that the nodes can disconnect or go down without having to wait for the
funding transaction to be confirmed on the blockchain.
Previously, the finalization of the funding process was handled by a
combination of the funding manager, the peer and the wallet, but if
the remote peer is no longer online or no longer connected, this flow
will no longer work. This commit moves all funding steps following
the transaction broadcast into the funding manager, which is available
as long as the daemon is running.
github.com/lightningnetwork/lnd master ✗
0m ◒
▶ golint
htlcswitch.go:292:4: should replace numUpdates += 1 with numUpdates++
htlcswitch.go:554:6: var onionId should be onionID
htlcswitch.go:629:7: var onionId should be onionID
lnd_test.go:133:1: context.Context should be the first parameter of a
function
lnd_test.go:177:1: context.Context should be the first parameter of a
function
networktest.go:84:2: struct field nodeId should be nodeID
peer.go:1704:16: should omit 2nd value from range; this loop is
equivalent to `for invoice := range ...`
rpcserver.go:57:6: func newRpcServer should be newRPCServer
github.com/lightningnetwork/lnd master ✗
9m ⚑ ◒ ⍉
▶ go vet
features.go:12: github.com/lightningnetwork/lnd/lnwire.Feature
composite literal uses unkeyed fields
fundingmanager.go:380: no formatting directive in Errorf call
exit status 1
This commit adds support for pushing funds during the funding process
to the helper method in the integration testing framework.
Additionally, we also modify the simple testBasicChannelFunding test to
also push over an amount in order to test the functionality within the
daemon.
This commit makes a large number of minor changes concerning API usage
within the deamon to match the latest version on the upstream btcsuite
libraries.
The major changes are the switch from wire.ShaHash to chainhash.Hash,
and that wire.NewMsgTx() now takes a paramter indicating the version of
the transaction to be created.
This commit alters the configuration parsing a bit along with the
documentation to expect the RPCHost configuration paramter to also have
the target port specified. If the port isn’t included, then the default
btcd RPC port for that chain is used.
Additionally, within the integration testing framework, when creating
the lnd nodes, we now use the configuration from the btcd harness to
set the proper RPC host.
Moved transaction states from in-memory maps to persistent BoltDB
buckets. This allows channel force closes to operate reliably if the
daemon is shut down and restarted at any point during the forced
channel closure process.
This commit adds a callback to the RestartNode method on the network
harness in order to allow test authors to execute arbitrary logic
in-between the restart process for the node.
This commit adds a new feature to the network harness: test writers are
now able to select arbitrary nodes, causing them to restart.
This functionality will be useful in the future in order to test
scenarios like persisting data across restarts, re-syncing after
re-connections, reacting to the counter party broadcasting revoked
states, etc.
This commit fixes a panic bug caused by two calls to a process’
cmd.Wait() method. If two nodes incurred a fatal error as soon as they
were created, then both the goroutine detected to recovering the stderr
data and the defer statement would case a double channel close due to
the simultaneous calls to Wait().
This commit slightly modifies the existing CT struct in order to
maintain consistency with code-style. As a result of the name change,
all references have also been renamed from `ct` to `t`.
The Error and Errorf methods have been removed in favor of forcing
everything to be reported via `Fatalf`. Additionally a new method
(ProcessErrors) has been introduced to the networkHarness class in
order to encapsulate the underlying channel.
This commit uses the context package’s WithTimeout to ensure tests
which rely on asynchrony behaviors cannot block the execution of the
integration tests for ever. All tests which rely on async gRPC
notifications now perform a 3 way select: on the timeout channel
closure, an error, and the response itself.
Additionally some slight refactoring has taken place within the current
set of integration tests, eliminating some unneeded factory functions.
This commit adds a new RPC command: `channelbalance` which returns the
sum of all available channel capacity across all open channels. The
total balance is currently returned in units of `satoshis`. Additionally
the `networkHarness` has been modified slightly to allow specifying the
additional "extra" command line parameters when creating the initial
seed nodes. Minor refactoring within the integration tests has been
undertaken in order to increase code re-use across tests.
Closes#29.
This commit modifies the OpenChannel helper method within the
networkHarness to open the channel according to the destination node’s
global lighting ID rather than using a hard coded peer ID as before.
With this change the method is now much more general as the prior
temporary hack has been removed.
This commit introduces the concept of a manually initiated “force”
closer within the channel state machine. A force closure is a closure
initiated by a local subsystem which broadcasts the current commitment
state directly on-chain rather than attempting to cooperatively
negotiate a closure with the remote party.
A force closure returns a ForceCloseSummary which includes all the
details required for claiming all rightfully owned outputs within the
broadcast commitment transaction.
Additionally two new publicly exported channels are introduced, one
which is closed due a locally initiated force closure, and the other
which is closed once we detect that the remote party has executed a
unilateral closure by broadcasting their version of the commitment
transaction.
At times when testing one requires access to the logs of a particular
node in order to aide with debugging. Before this commit, one needed to
manually modify the networkHarness code in order to print either the
location of the logs or the logs themselves. With this commit, tests
can now programmatically examine the logs of any node created within
the networkHarness.
It’s worth noting that at times the logs dumped may not be the most up
to date version of the logs files as the logging library employs
intermediate buffering.
This commit fixes some flakiness exhibited in the current basic funding
workflow tests. This test can fail occasionally in resource constrained
environment due to a race condition which arises after Alice learns of
the channel, but Bob is still waiting for Alice’s notification. As a
temporary fix, we now only check Alice’s state for the existence of the
channel.
This commit adds some new networkHarness helper methods which are
mean’t to reduce the verbosity of the previous basic tests, and also to
enable developers to right tests mote easily five a higher level
interface.
