This commit adds a new component, harness miner, to the itest. This
newly added component is responsible for checking the mempool and blocks
for the itest.
This commit adds a new struct RPCClients to better handle rpc clients.
A private field, rpc, is added to HarnessNode to prevent direct access
to its clients. Inside RPCClients, all clients are exported in case a
test case need access to a specific client.
This commit adds a method to resend premature when new blocks arrive.
Previously when a message has specified a block+delta in the future, we
would ignore the message and never process it again, causing an open
channel never being broadcast under fast blocks generation. This commit
fixes it by saving the future messages and resending them once the
required block height is reached.
This commit moves syncing blocks into a dedicated goroutine to avoid the
race condition where several go channels are ready and the block height
update is pushed after a network message is processed.
This commit fixes the issue where duplicate peers are used both in
making persistent connections and bootstrap connections. When we init
bootstrapping, we need to ignore peers that have connections already
made so far plus peers which we are attempting to make connections with,
hence the persistent peers.
Fixed PR feedback
Fixed name of xcode framwork file, and added section on dependency on Swift Protobuf in Xcode
Added link to https://api.lightning.community
Link to PR
The log message was confusing because it was emitted even when running
within systemd if the service type was **not** `notify`. This clarifies
the message by mentioning the edge case.
Being able to distinguish the two cases would be nicer but there doesn't
seem to be a reasonably simple, obvious, reliable way to do it.
Complicated solutions are most likely not worth it for a simple log
message.
In this commit, we switch to always sending a channel type when we're in
explicit mode. This is compatible with prior versions of lnd as they
won't send a channel type, and we'll just arrive at the same type via
the existing implicit funding.
Fixes https://github.com/lightningnetwork/lnd/issues/6067
This commit fixes a potential blocking when notifying invoice updates.
When a new subscription client is created followed by an immediate
cancel, it's likely the client will be removed from the registry's
map(noop) and then added to its map again. This subscription will then
be kept in registry until lnd is restarted. Another more serious issue
is when multiple subscriptions are made for the same invoice, when the
above case happens, other subscriptions may never send invoice updates
because a previous client has a stopped notification queue that blocks
following notifications.
