Checkout v1 has a known flake:
https://github.com/actions/checkout/issues/23#issuecomment-572688577.
For our linter to pass, we need to checkout our full history (default
depth is 1 commit). We could set fetch-depth, but we will eventually
move that depth past the linter's start point commit and need to
implement another fix. Indead, we add an extra step in our linter to
fetch full history so that the linter reference commit is found.
These race conditions originate from the mock database storing and
returning pointers, rather than returning a copy.
Observed on Travis:
WARNING: DATA RACE
Read at 0x00c0003222b8 by goroutine 149:
github.com/lightningnetwork/lnd/watchtower/wtclient.(*sessionQueue).drainBackups()
/home/runner/work/lnd/lnd/watchtower/wtclient/session_queue.go:288 +0xed
github.com/lightningnetwork/lnd/watchtower/wtclient.(*sessionQueue).sessionManager()
/home/runner/work/lnd/lnd/watchtower/wtclient/session_queue.go:281 +0x450
Previous write at 0x00c0003222b8 by goroutine 93:
github.com/lightningnetwork/lnd/watchtower/wtclient.getClientSessions()
/home/runner/work/lnd/lnd/watchtower/wtclient/client.go:365 +0x24f
github.com/lightningnetwork/lnd/watchtower/wtclient.(*TowerClient).handleNewTower()
/home/runner/work/lnd/lnd/watchtower/wtclient/client.go:1063 +0x23e
github.com/lightningnetwork/lnd/watchtower/wtclient.(*TowerClient).backupDispatcher()
/home/runner/work/lnd/lnd/watchtower/wtclient/client.go:784 +0x10b9
The logger string used to identify the wtclient and wtclientrpc loggers
was the same, leading to being unable to modify the log level of the
wtclient logger as it would be overwritten with the wtclientrpc's one.
To simplify things, we decide to use the existing RPC logger for
wtclientrpc.
The continue-on-error was added to make sure the log files of the
failed itests would always be uploaded. But this has the side effect
of marking the whole job successful, even if the itest job itself
failed. The failure condition in the log file steps already solve
that, so the continue-on-error is not needed anymore.
This adds a test to the commit sweeper resolver to ensure it behaves
properly if the local node breaches a channel.
In this situation the remote party is expected to sweep the breached
output to itself and therefore the local party won't be able to recover
any funds.
This fixes an issue where the contract court could leave a completely
swept commit tx unresolved if it was swept by the remote party.
This could happen if (our) commit tx just published was actually a
previously revoked state, in which case the remote party would claim the
funds via a justice transaction.
This manifested itself in the testRevokedCloseRetribution integration
test where at the end of the test Bob was left with a pending channel
that never resolved itself.
