What the developer wrote
Authored by Abdullahi Yunus
itest: check for config addrs precedence
In this commit, we update the itest to check for precedence of the
config addresses over the persisted addresses.
We did not check for address persistence after restart (without the
extraArgs `--externalip`) because in `lntest/node/config.goL300`,
`GenArg` by default sets the `--externalip` flag, which makes
the config addrs to always take precedence over the persisted
addrs, for the tests.
What changed, and why it matters
This commit only changes an integration test file. It adjusts the test expectations so that the test now verifies that command-line configuration addresses take precedence over addresses that were previously updated and persisted via RPC. There is no change to production code, no fix for a security bug, and no disclosed security relevance.
No security action required. This is a test-only change. Reviewers may optionally confirm the new test expectations accurately reflect the intended product behavior for config vs persisted address precedence.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The diff modifies itest/lnd_channel_graph_test.go in the testSelfNodeAnnouncementPersistence test. It removes a redundant post-restart assertion without --externalip, reorders the address-removal check, and updates assertions so that after restart with --externalip flags, only the config-supplied addresses are expected. The commit message explicitly frames this as an itest update to check config address precedence over persisted addresses. No production logic is changed.
Changed components
itest/lnd_channel_graph_test.goInspect captured patch +17 / −26
diff --git a/itest/lnd_channel_graph_test.go b/itest/lnd_channel_graph_test.go
index 6d30fe2..f8d63c1 100644
--- a/itest/lnd_channel_graph_test.go
+++ b/itest/lnd_channel_graph_test.go
@@ -728,25 +728,7 @@ func testSelfNodeAnnouncementPersistence(ht *lntest.HarnessTest) {
}
assertUpdateNodeAnnouncementResponse(ht, response, expectedOps)
- resp = alice.RPC.GetInfo()
- assertNodeInfo(
- resp, "alice", "#eeeeee", "192.168.1.10:8333",
- "192.168.1.11:8333",
- )
-
- // Restart Alice.
- ht.RestartNode(alice)
-
- // After restarting, the node info should contain the values that were
- // set in the update request since the updated values take precedence
- // over the default values.
- resp = alice.RPC.GetInfo()
- assertNodeInfo(
- resp, "alice", "#eeeeee", "192.168.1.10:8333",
- "192.168.1.11:8333",
- )
-
- // Test that we can still remove an address.
+ // Test that we can remove an address.
removeAddrReq := &peersrpc.NodeAnnouncementUpdateRequest{
AddressUpdates: []*peersrpc.UpdateAddressAction{
{
@@ -761,6 +743,20 @@ func testSelfNodeAnnouncementPersistence(ht *lntest.HarnessTest) {
}
assertUpdateNodeAnnouncementResponse(ht, response, expectedOps)
+ resp = alice.RPC.GetInfo()
+ assertNodeInfo(
+ resp, "alice", "#eeeeee", "192.168.1.11:8333",
+ )
+
+ // Restart Alice.
+ ht.RestartNode(alice)
+
+ // After restarting, the node info should contain the values that were
+ // set in the update request since the updated values take precedence
+ // over the default values.
+ resp = alice.RPC.GetInfo()
+ assertNodeInfo(resp, "alice", "#eeeeee")
+
// Now we restart the node with custom values in the config.
lndArgs := []string{
"--externalip=192.168.1.12:8333",
@@ -772,16 +768,11 @@ func testSelfNodeAnnouncementPersistence(ht *lntest.HarnessTest) {
// Get the node info and verify that the values are the same as the
// ones we set in the config (and not the updated values).
- // The addresses should be the same as the ones we set in the config
- // plus the ones we set in the update request earlier.
resp = alice.RPC.GetInfo()
assertNodeInfo(
- resp, "alice-updated", "#ffffff", "192.168.1.11:8333",
- "192.168.1.12:8333", "192.168.1.13:8333",
+ resp, "alice-updated", "#ffffff", "192.168.1.12:8333",
+ "192.168.1.13:8333",
)
-
- // The address we removed earlier should not be present.
- require.Error(ht, assertAddrs(resp.Uris, "192.168.1.10:8333"))
}
// assertSyncType asserts that the peer has an expected syncType.
Why this scored 12/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.