WellKnownHandleResolver eats the error thrown by safeFetch's unicast protection #4215

Describe the bug

I was attempting to use the NodeOAuthClient without a custom handleResolver or idResolver, and had configured my server to respond to both /.well-known/atproto-did and /.well-known/did.json correctly, however my oauth calls still failed at handle resolution.

It turned out that safeFetch was throwing on unicast error, since for my local environment, handle.princess.works resolves to 127.0.0.1, however this unicast error is swallowed by WellKnownHandleResolver so you have no idea that that's the reason why it's failing.

Additionally, passing a custom fetch to NodeOAuthProvider still somehow trips the unicast detector, even with:

import { safeFetchWrap } from "@atproto-labs/fetch-node";

const safeFetch = safeFetchWrap({
  allowIpHost: true,
  allowPrivateIps: true,
  allowImplicitRedirect: false,
  ssrfProtection: false,
  fetch: fetch,
});

export const createClient = async (ctx: Omit<AppContext, "oauthClient">) => {
  const url = ctx.service.url;

  return new NodeOAuthClient({
    fetch: fetch
    clientMetadata: { /* ... */ }
  })
}

Expected behavior

The unicast safeFetch error should probably bubble up from WellKnownHandleResolver, such that you can understand why it's failing.

I'm not sure why passing a custom fetch implementation doesn't solve the problem though.

Details

• Operating system: MacOS Sequoia
• Node version: v24.7.0