Repository navigation
pin-proxy: move a connection back to a node that answers again - #10
Merged
Merged
Conversation
While a node is down, the proxy sends its connection to another, so one node ends up with both. Since the litecoinds stopped evicting the autoforward hosts (whitelist=noban), those connections never close, and nothing moved one back: after eu-01's restart on 2026-10-26 both of each container's P2P connections stayed on usa-01 until closed by hand. Once a minute, if one node holds two or more connections and another holds none, the proxy test-connects to the idle node. If it answers, the proxy closes the busiest node's newest connection. mwebd redials, and the least-used order sends the redial to the idle node. While that node is still down, nothing is closed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
pin-proxy.pynow moves an MWEB connection back to a Litecoin node once that node is reachable again.Why
While a node is down, the proxy sends its connection to the other node, which is right. But now that the litecoinds exempt the autoforward hosts from eviction (
whitelist=noban), those connections never close, so nothing moved one back. After eu-01's restart on production (2026-10-26), both of each LTC container's P2P connections stayed on usa-01, leaving MWEB dependent on one node until I closed one by hand.What
Once a minute, if one node holds two or more connections and another holds none:
In normal operation, with one connection per node, the check does nothing and makes no connection.
Tests
tests/test_pin_proxy.pyadds two cases:The full suite passes (28 tests), as does pyflakes 3.2.0.
Staging (btcpay-usa-dev-01, dry run)
I didn't restart a production litecoind for the test. Staging ran temporarily with
MWEB_PEERSset to litecoin-fulcrum-eu-dev-01 and usa-01, and I restarted the dev litecoind::9333socketsdocker restart litecoindon eu-dev-01Both mwebds stayed caught up (3202027), and the
ltc/ltc-mwebpasses logged no errors. Afterwards I redeployed staging on its normal peers (eu-01, usa-01). The LTC wallet volumes were backed up first. Production hasn't been touched.