Atlas shows duplicates shown when a bridge changes to a publicly listed node.

If a node is running as a bridge with PublishServiceDescriptor bridge then changes to a regular node without resetting it's fingerprint, that node will have 2 identical entries forever.

I have reproduced here: https://atlas.torproject.org/#search/30AFA68C0F9B30C213F19B6CE57F7D8CA4B77A25

Trac:
Username: entry

added component::metrics/relay search owner::metrics-team priority::very low reporter::entry resolution::fixed severity::trivial status::closed type::defect labels

Trac:
Username: entry
Summary: Atlas showz duplicates shown when a bridge changes to a publicly listed node. to Atlas shows duplicates shown when a bridge changes to a publicly listed node.

Seems like that might be a feature? Since there are the stats about it when it was a bridge, and the stats about it when it was a relay, and we would want onionoo to track each of them.

Oh -- on the example atlas page, both entries are listed as 'relay'. That definitely sounds like a bug.

This is caused by js/models/relay.js#n136 which processes only the first relay or bridge (with a preference for the relay in the case of both). In this case Atlas requests the summary document which returns the relay and bridge. For both the detail document is requested which returns the relay and the bridge. The response for the bridge contains both the relay and the bridge where Atlas takes preference for the relay details and ignores the bridge details leading to duplicate results.

It seems using the fingerprint (instead of the lookup) parameter returns the responses that Atlas expects.

https://onionoo.torproject.org/details?fingerprint=30AFA68C0F9B30C213F19B6CE57F7D8CA4B77A25 https://onionoo.torproject.org/details?fingerprint=D752CBAB72003DE7774D032186A47ACE09CD27C1

Trac:
0001-Use-fingerprint-searches-for-the-detail-documents.patch

Trac:
Status: new to needs_review

The patch fixes the issue on the search page but the results link to the incorrect details page. Please ignore the patch for now.

Trac:
Status: needs_review to needs_revision

This is an issue with Atlas which incorrectly duplicates search results so I'm changing the component.

Trac:
Keywords: atlas deleted, N/A added
Component: Metrics to Metrics/Atlas

Replying to cypherpunks:

The patch fixes the issue on the search page but the results link to the incorrect details page. Please ignore the patch for now. The results do not link to the incorrect details pages. It is Atlas always using hashed fingerprints for Onionoo requests which does not work with the fingerprint parameter. Atlas hashes the given fingerprints to prevent bridge fingerprints from being leaked but in this case it prevents searches for exact matches.

I'm unsure about how to continue now. On one hand we want exact matches (especially for the details page because it presents information about a specific relay or bridge) which means we should pass on the exact fingerprint the user gives us. On the other hand we want to protect the user from leaking bridge fingerprints which forces us to use the lookup parameter which can return multiple results with no good way to select one of the results.

Thinking about it some more i believe the solution is to rehash the fingerprints Onionoo returns in the summary response. This will turn the details requests using the lookup parameter into

https://onionoo.torproject.org/details?lookup=D752CBAB72003DE7774D032186A47ACE09CD27C1 for the relay. https://onionoo.torproject.org/details?lookup=BD2734E77BEBA086B9718091B6D11A75422E4770 for the bridge.

The first request returns both relay and bridge where Atlas will only parse the relay as explained in comment:4. The second request returns only the bridge so Atlas can and will only parse the bridge.

This solution was discussed previously in #21615 (moved) in a different context but was closed as not a bug. Now it turns out it is a bug so i'll reopen and make this ticket the parent.

I believe this was fixed in 40426f09f37ff84f93f20f156ab638ce27ff977a to be deployed shortly. Please reopen if this is still a problem, and provide some example fingerprints to test.

Trac:
Resolution: N/A to fixed
Status: needs_revision to closed

closed