new Request(url, { headers: <Proxy over a record> }) silently drops the headers #10274

Summary

new Request(url, { headers: <Proxy over a record> }) silently produces empty headers; bun/node produce the header. A Headers built directly from the same proxy is correct (that path is fixed in the PR referenced below), so only the Request init path is affected.

Repro

const dump = (h: any) => { const out: string[] = []; h.forEach((v: string, k: string) => out.push(k + "=" + v)); return out.sort() }
const proxy = new Proxy({ "x-a": "1" }, {})
console.log("direct   ", dump(new Headers(proxy as any)))                                  // both: ["x-a=1"]
console.log("request  ", dump(new Request("https://x.dev", { headers: proxy as any }).headers))

bun 1.3.14: request ["x-a=1"] — perry: request [].

Silently dropping headers is worse than throwing: a request just goes out without its authorization or content-type header.

Notes

• js_headers_init_from_value (perry-stdlib fetch/headers.rs) handles a proxied record correctly once the record path accepts proxies. The Request path does not end up there with the proxy value, so the conversion happens somewhere else (request_ctor.rs reads init.headers and calls that helper; codegen also has a compile-time build_headers_from_object for literal inits in lower_call/options/). Worth checking which of the two runs for a dynamic (non-literal) headers value.
• Found while making OpenCode's request path work under perry (tracker tracking: OpenCode v1.18.30 — complete native build from real TypeScript (no stripping, no bundle), startup faster than bun #10107); the AI SDK hands the fetch layer a proxied header record.