lightningd: don't explicitly tell connectd to disconnect, have it do it on sending error/warning.

Connectd already does this when we *receive* an error or warning, but
now do it on send.  This causes some slight behavior change: we don't
disconnect when we close a channel, for example (our behaviour here
has been inconsistent across versions, depending on the code).

When connectd is told to disconnect, it now does so immediately, and
doesn't wait for subds to drain etc.  That simplifies the manual
disconnect case, which now cleans up as it would from any other
disconnection when connectd says it's disconnected.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell
2022-07-18 21:42:28 +09:30
committed by neil saitug
parent 2962b93199
commit a3c4908f4a
16 changed files with 75 additions and 146 deletions

View File

@@ -641,33 +641,6 @@ void connectd_activate(struct lightningd *ld)
assert(ret == ld->connectd);
}
void maybe_disconnect_peer(struct lightningd *ld, struct peer *peer)
{
struct channel *channel;
/* Any channels left which want to talk? */
if (peer->uncommitted_channel)
return;
list_for_each(&peer->channels, channel, list)
if (channel_is_connected(channel))
return;
/* If shutting down, connectd no longer exists.
* FIXME: Call peer_disconnect_done(), but nobody cares. */
if (!ld->connectd) {
peer->connected = PEER_DISCONNECTED;
return;
}
/* If connectd was the one who told us to cleanup peer, don't
* tell it to discard again: it might have reconnected! */
if (peer->connected == PEER_CONNECTED)
subd_send_msg(ld->connectd,
take(towire_connectd_discard_peer(NULL, &peer->id,
peer->connectd_counter)));
}
static struct command_result *json_sendcustommsg(struct command *cmd,
const char *buffer,
const jsmntok_t *obj UNNEEDED,