If a routing query completes with no results, an empty list should be returned instead of a 404, as if the query is made from a browser, some browsers log ugly error messages in an unpreventable way, even though the actual error is handled in code and execution continues as normal.

This unpreventable "error" message confuses users who (quite understandably) think something is broken.

Put another way, if I request a resource (the list), it's ok for the resource to be empty. This is a different outcome to the resource not existing at all, which is what the 404 response implies and why some browsers feel it is necessary to log an error message.

For example, this peer has addresses:

https://delegated-ipfs.dev/routing/v1/peers/bafzaajaiaejcbtj6e4jp4xvbxguv2deisz5nx2jzqk2hgxrkn2bufohzprze662c

Applying a filter to the same peer causes a 404 with a null Peers property in the result envelope, instead if should return a 200 with Peers set to []:

https://delegated-ipfs.dev/routing/v1/peers/bafzaajaiaejcbtj6e4jp4xvbxguv2deisz5nx2jzqk2hgxrkn2bufohzprze662c?filter-addrs=https%2Cwebtransport%2Cwebrtc%2Cwebrtc-direct%2Cwss%2Ctls&filter-protocols=unknown%2Ctransport-bitswap%2Ctransport-ipfs-gateway-http

A 404 should only be returned if the routing query endpoint does not exist, which it does, hooray:

https://delegated-ipfs.dev/routing/v1/not-an-endpoint