feat(dir): dht only remote discovery

[tkircsi]

Closes #1972

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: e47f92c7-27d2-4700-9237-51fdb80882be

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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

[codecov]

Codecov Report

❌ Patch coverage is 85.63218% with 100 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
server/routing/routing_local.go	78.5%	17 Missing ⚠️
server/routing/advertise.go	86.0%	15 Missing ⚠️
server/routing/migrate_published.go	73.7%	15 Missing ⚠️
server/routing/routing.go	50.0%	15 Missing ⚠️
server/routing/search_remote.go	91.4%	12 Missing ⚠️
...m/migrations/004_purge_orphaned_record_children.go	41.2%	10 Missing ⚠️
server/routing/routing_remote.go	83.3%	4 Missing ⚠️
reconciler/tasks/metrics/task.go	94.1%	2 Missing ⚠️
server/database/gorm/record.go	81.8%	2 Missing ⚠️
server/database/gorm/record_labels.go	91.7%	2 Missing ⚠️
... and 4 more

📢 Thoughts on this report? Let us know!

[csirmazbendeguz]

In the issue you mentioned that to migrate to v2, users need to delete the routing datastore directory.
Can we do this in a migration automatically?

[tkircsi]

@csirmazbendeguz Thanks! I investigated it and yes, we can. We just need to create the datastore in subdirectory where the subdir's name is the ProtocolPrefix so v2. I'll add this to this branch soon.

[tkircsi]

Thanks @paralta for review!

discoveryKey in server/routing/search_remote.go picks the single deepest label out of a multi-query Search, runs one FindProvidersAsync on it, and contacts only the peers that lookup returns.

That holds for an AND query — a matching record carries every queried label, so any one of them finds the holder. But Search is OR-with-threshold, and min_match_score defaults to 1. A peer holding records that match only a different, non-selected query never advertised the chosen label, so it is never discovered, never asked, and its matches are silently missing: no error, no truncation flag.

Discovery is the only stage still assuming AND. The proto, rpc.matchingCIDs ("runs each query separately and unions the results"), rpc.QueryRecordsRequest ("Queries are OR'd") and scoreMatch all implement OR.

Worth separating from the best-effort caveat already documented in #1972. That one is Kademlia reaching whoever it can inside a budget; this is a reachable peer that discovery structurally cannot see, however long you wait.

Fix. Look up every distinct query label, run the lookups concurrently, union the peer sets. Nothing downstream changes — queryPeer already forwards the full query set. Three details: share one SearchDiscoveryTimeout across the lookups rather than per-lookup, widen the seen peer dedupe to span them, and bound the concurrency. The single-label shortcut stays valid when minMatchScore == len(queries) and could be kept behind that condition.