web: resolve related-entity names on facility detail#22
Merged
Conversation
PeeringDB's association objects (carrierfac, netfac, ixfac) carry a
`name` field set to the facility's name, not the related entity's. The
facility detail page used that join `name` directly as the carrier,
network, and exchange name, so every related row rendered the facility's
own name. On a facility like Global Switch Paris, all carriers (and all
networks) displayed "Global Switch Paris" instead of their real names.
Resolve the names from the related-entity edge instead: load Carrier,
Network, and InternetExchange via WithCarrier/WithNetwork/
WithInternetExchange and read the edge's name. This affects both the
browser fragments (handleFac{Networks,Carriers}Fragment) and the
terminal/JSON path (queryFacility); the IXP fragment already used the
edge, but queryFacility did not.
The previous ordering used ByName(), which sorts on the constant
facility name and left the "pre-sorted alphabetically" sections
effectively unordered. Order by the related entity's name via the
generated edge-field order helpers so the carrier and IXP lists are
genuinely alphabetical.
The /api, REST, GraphQL, and gRPC surfaces are intentionally untouched:
there carrierfac.name == facility name is the correct upstream contract.
This was solely a web-UI presentation bug.
The test seed encoded the bug (the ixfac row's name was set to the IX
name, and the fragment assertions expected the facility name as the
carrier/network name). Seed all three association rows with the facility
name, as upstream does, and assert the related-entity names with
negative guards that the facility name no longer leaks.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Code Metrics Report
Code coverage of files in pull request scope (69.7%)
Reported by octocov |
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
1 participant
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.
Problem
On a facility detail page (e.g.
/ui/fac/181, Global Switch Paris), every carrier rendered as "Global Switch Paris" — the facility's own name. The same bug affected the networks list (masked because each row also shows its ASN) and the terminal/JSON IXP list.Root cause: PeeringDB's association objects (
carrierfac,netfac,ixfac) set theirnamefield to the facility's name, not the related entity's. Confirmed against the live API — fac 181's 5carrierfacrows have distinctcarrier_ids but everynameis"Global Switch Paris". The web UI used that joinnamedirectly as the carrier/network/exchange name.Fix
Resolve the names from the related-entity edge (
WithCarrier/WithNetwork/WithInternetExchange) instead of the association row'sname. This corrects:handleFacNetworksFragment,handleFacCarriersFragment(the IXP fragment already used the edge).queryFacility(all three sections, including IXPs).Also fixed ordering: the old
ByName()sorts on the constant facility name, so the "pre-sorted alphabetically" carrier/IXP sections were effectively unordered. Now they order by the related entity's name via the generated edge-field order helpers.The
/api, REST, GraphQL, and gRPC surfaces are intentionally untouched — therecarrierfac.name == facility nameis the correct upstream contract (drop-in parity). This was solely a web-UI presentation bug.Tests
The seed and assertions previously encoded the bug (the fragment test asserted the carrier row equalled the facility name). Updated the seed so all three association rows carry the facility name as upstream does, added
TestQueryFacility_RelatedEntityNames, and added negative guards that the facility name no longer leaks as a related-entity name.go test -race ./...,go vet ./..., andgolangci-lint runall pass; no generated-code drift.🤖 Generated with Claude Code