Skip to content

Conversation

@jagerman
Copy link
Member

When a node leaves the network, currently we just keep an established connection to that node alive as long as it stays up.

This fixes that by adding a check for deregged nodes and, if found, disconnects them after half an hour.

The delay here is to attempt to not kill existing client paths that may still be using a path through us to the deregged node, allowing some time for the client to replace the path with new paths that don't use it.

@jagerman jagerman force-pushed the disconnect-deregged branch 3 times, most recently from c9fdfe9 to dac05fc Compare October 31, 2025 00:30
When a node leaves the network, currently we just keep an established
connection to that node alive as long as it stays up.

This fixes that by adding a check for deregged nodes and, if found,
disconnects them after half an hour.

The delay here is to attempt to not kill existing client paths that may
still be using a path through us to the deregged node, allowing some
time for the client to replace the path with new paths that don't use
it.
Actually close the connections.

Quiet closing doesn't seem to have a purpose, and moreover seems like a
hack to avoid having to deal with proper callbacks, so this changes all
the "close quietly" to just "close".

This ended up triggering warnings in the close callback about closing an
untracked connection, so this also addresses those by using a specific
close error code for those connections so that we can detect them and
debug instead of warn for them.
@jagerman jagerman force-pushed the disconnect-deregged branch from 4fd1149 to 18470c1 Compare October 31, 2025 17:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant