Previously we'd restart Alice and then restart Bob, which means once
Alice is shut down and started again before we shut down Bob, Bob will
attempt to connect Alice since the connection is permanent, which could
put the node in a weird state. We now make sure both nodes are shut down
first, then bring them back online to avoid the above case. We may,
however, create another test in the future to check the above case if needed.
Previously, we would set the state of the syncer after sending the msg,
which has the following flow,
1. In state `queryNewChannels`, we send the msg `QueryShortChanIDs`.
2. Once the msg is sent, we change to state `waitingQueryChanReply`.
But there's no guarantee the remote won't reply back inbetween the two
step. When that happens, our syncer would still be in state
`queryNewChannels`, causing the following error,
```
[ERR] DISC gossiper.go:873: Process query msg from peer [Alice] got unexpected msg *lnwire.ReplyShortChanIDsEnd received in state queryNewChannels
```
To fix it, we now make sure the state is updated before sending the msg.
After merging #9581, the flake in the coverage unit test should be gone.
All we have to do is update the submodule version to the fixed one
(since during unit tests the module is used not the physical directory
on disk).
This commit adds an integration test that
verifies the funding timeout behavior in the
funding manager, in dev/integration test.
Signed-off-by: Nishant Bansal <nishant.bansal.282003@gmail.com>
Nudging test authors towards not mining too many blocks makes sense,
especially in lnd where we have a lot of integration tests.
But the lntest package is also used in other projects where this
restriction might lead to large refactors.
To be able to stage those refactors we also want to allow this limit to
be configurable if lntest is used as a library.
This commit adds a test to demonstrate that if we receive two identical
updates (which can happen if we get the same update from two peers in
quick succession), then our rate limiting logic will be hit early as
both updates might be counted towards the rate limit. This will be fixed
in an upcoming commit.
Before this commit, it was possible for a request to be sent on the
`chanWatchRequests` channel in `WaitForChannelPolicyUpdate` and then for
the `ticker.C` case to select _before_ the `eventChan` select gets
triggered when the `topologyWatcher` closes the `eventChan` in its call
to `handlePolicyUpdateWatchRequest`. This could lead to a "close of a
closed channel" panic.
To fix this, this commit ensures that we only move on to the next
iteration of the select statement in `WaitForChannelPolicyUpdate` once
the request sent on `chanWatchRequests` has been fully handled.
