Fix listener matched status using aggregated network addresses

[AryanP123]

Fixes #2428

Summary by CodeRabbit

• Bug Fixes
  • Improved network status handling so binding status can recognize matching connectors and listeners from network address information.
  • Binding and listener status updates now remain accurate when matching entries are represented through address data rather than local records.

[coderabbitai]

📝 Walkthrough

Walkthrough

Network address data now flows from controller status updates into binding-status computation. Matching connector and listener checks use aggregated address counts when local connector or listener records are unavailable.

Changes

Network address matching

Layer / File(s)	Summary
Propagate network addresses internal/kube/controller/controller.go, internal/kube/site/site.go, internal/kube/site/site_test.go	NetworkStatusUpdated accepts network addresses. The controller passes status.Addresses, and the test call uses the updated signature.
Use address counts for matching internal/kube/site/binding_status.go	Binding status stores network addresses and falls back to ConnectorCount and ListenerCount when local records do not match. Matching listener counts and multi-key destinations use the same fallback.

Estimated code review effort: 2 (Simple) | ~15 minutes

Merge Risk: 🔵 Low · up to 0f8e9

Listener and connector status now uses aggregated remote address counts, but the new matching path lacks regression coverage. A future change could silently reintroduce incorrect Pending or no-match status for remote connectors.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 3 functions across 4 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: fixing listener matched status by using aggregated network addresses.
Linked Issues check	✅ Passed	The changes satisfy issue #2428 by passing aggregated address data into binding-status reconciliation and using remote connector counts when local records are unavailable.
Out of Scope Changes check	✅ Passed	All changes support the linked issue. The API update, address fallback logic, controller call, and test adjustment are directly related to the listener status fix.

• Fix all pre-merge checks with AI

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: c531539e-caa4-489c-89eb-3dbacf896d68

📥 Commits

Reviewing files that changed from the base of the PR and between 44fb60f and 0f8e985.

📒 Files selected for processing (4)

• internal/kube/controller/controller.go
• internal/kube/site/binding_status.go
• internal/kube/site/site.go
• internal/kube/site/site_test.go

Included review availability: Your plan provides up to 4 included reviews per hour; 3 remain after this review.

[coderabbitai]

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Add a regression test for address-count matching.

This test passes nil for addresses, so it does not exercise the new remote matching path. Add cases with AddressInfo.ConnectorCount and AddressInfo.ListenerCount, then assert the listener and connector matching status.

[c-kruse]

@AryanP123 Can you explain what's going on here? I'm not sure I can make much sense of the changes here or the reporter's diagnosis. the status addresses and siteStatuses comes from the same source: if the connector-site's records were purged, the connector should have gone with it.

My best wild guess as to what's actually going on here, based on having flirted with changing this several times, is that this is a problem with the purge logic. Ex: network is up and the router at the docker site rD and the kube site are happily connected. A connector gets added to site D's configuration, so router rD is killed and replaced with rD'. At the kube site the collector sees rD' announce itself, and maybe it sees its CONNECTOR and SITE records with it. It also notices rD has gone away, so it purges rD's records, including the SITE that aught to now belong to rD', but still belongs to rD.

[AryanP123]

@c-kruse Yeah, fair point. siteStatus and addresses are built in the same pass in StatusSync.build(), so if remote site records get purged, the connector should disappear from both. Your rD -> rD' theory makes more sense.

This PR doesn't fix purge logic. It just makes kube BindingStatus check aggregated addresses too, like non-kube already does. The issue was that addresses showed connectorCount: 1 but the Listener still said "No matching connectors" because kube only looked at site records.

I couldn't repro it naturally with kind+podman, but I could trigger the same wrong status by editing the network status configmap to match what the reporter saw.

Happy to look at the purge path instead if you'd rather fix it there. Lmk what you think

[c-kruse]

@AryanP123 I think we should focus on the purge path instead: it should fix "both" bugs implicitly reported here (missing Site from network status, and inconsistent listener/connector status), and potentially similar network-observer bugs we haven't found yet with the same pattern.

All of this skupper-network-status + statusSync stuff is something we plan to deprecate in 2.3 and remove soon after (2.4?), if we focus on the purge/sources path instead we at least get one long-term fix (in the network-observer.)

Added #2568 with some more context from my previous attempts.