ipfs/kubo · error

GetClosestPeers not supported for DHT type %T

Error message

GetClosestPeers not supported for DHT type %T

What it means

Kubo's HTTP Routing API supports delegating GetClosestPeers to a known set of DHT client implementations (*dual.DHT, *fullrt.FullRT, *dht.IpfsDHT). If the node's DHTClient is any other type (or nil/uninitialized as a different type), the handler does not know how to perform the lookup and returns this error with the concrete Go type in the message. It acts as an exhaustiveness guard over the DHT type switch.

Source

Thrown at core/corehttp/routing.go:131

	if r.n.DHTClient == nil {
		return nil, fmt.Errorf("GetClosestPeers not supported: DHT is not available")
	}

	switch dhtClient := r.n.DHTClient.(type) {
	case *dual.DHT:
		// Only use WAN DHT for public HTTP Routing API.
		// LAN DHT contains private network peers that should not be exposed publicly.
		if dhtClient.WAN == nil {
			return nil, fmt.Errorf("GetClosestPeers not supported: WAN DHT is not available")
		}
		peers, err = dhtClient.WAN.GetClosestPeers(ctx, keyStr)
	case *fullrt.FullRT:
		peers, err = dhtClient.GetClosestPeers(ctx, keyStr)
	case *dht.IpfsDHT:
		peers, err = dhtClient.GetClosestPeers(ctx, keyStr)
	default:
		return nil, fmt.Errorf("GetClosestPeers not supported for DHT type %T", r.n.DHTClient)
	}

	// A lookup cut short by the deadline returns the closest peers found so far
	// along with the context error. The HTTP routing server caps every request
	// (server.DefaultRoutingTimeout), so on a slow query this is the difference
	// between a useful answer and a 500.
	if err != nil && len(peers) == 0 {
		return nil, err
	}

	// We have some DHT-closest peers. Find addresses for them.
	// The addresses should be in the peerstore.
	records := make([]*types.PeerRecord, 0, len(peers))
	for _, p := range peers {
		addrs := r.n.Peerstore.Addrs(p)
		rAddrs := make([]types.Multiaddr, len(addrs))
		for i, addr := range addrs {
			rAddrs[i] = types.Multiaddr{Multiaddr: addr}

View on GitHub (pinned to 329838acdf)

Solutions

  1. Check the node's routing configuration and switch to a supported mode that instantiates a known DHT client: `ipfs config Routing.Type dhtclient` (or `dhtserver`) and restart the daemon.
  2. If embedding kubo, ensure you assign one of the supported types (*dual.DHT, *fullrt.FullRT, *dht.IpfsDHT) to node.DHTClient.
  3. If you maintain a fork or a new DHT implementation, add a case for that type in the type switch in core/corehttp/routing.go to dispatch GetClosestPeers appropriately.
  4. As a client, catch this error and fail over to another routing provider that supports the operation.

Example fix

// Embedder: before
node.DHTClient = myCustomRouter // unsupported type
// after
node.DHTClient = dual.New(ctx, dhtLAN, dhtWAN) // or fullrt/dht.IpfsDHT
Defensive patterns

Strategy: type-guard

Type guard

func supportedDHT(n *core.IpfsNode) bool {
    switch n.DHTClient.(type) {
    case *dual.DHT, *fullrt.FullRT, *dht.IpfsDHT:
        return true
    default:
        return false
    }
}

Try / catch

peers, err := rt.GetClosestPeers(ctx, key)
if err != nil && strings.Contains(err.Error(), "not supported for DHT type") {
    return useAlternativeRouting(ctx, key) // e.g. delegated routing client
}

Prevention

When it happens

Trigger: Calling the GetClosestPeers HTTP Routing endpoint on a node whose `node.DHTClient` is set to an implementation outside the supported switch cases — e.g. a nil DHTClient, a custom/mock routing implementation, or a future DHT type not yet handled in core/corehttp/routing.go.

Common situations: Running a node built with custom routing (e.g. delegated routing only, `Routing.Type=delegated`, or `none`) so no supported DHT client is instantiated; embedding kubo as a library and injecting a custom DHTClient implementation; version drift where a new DHT type was added but corehttp/routing.go was not updated.

Related errors

AI-assisted analysis of ipfs/kubo@329838acdf (2026-09-03). Data as JSON: /api/errors/79d81ea65560f643. Report an issue: GitHub.