It seems the customFetch used in the custom httpLink and httpBatchLink does not copy over the response headers. Consequently, response headers become undefined in links downstream.
This is a snippet of the customFetch function, which adds the resolved json to the response object. However, response.headers is not copied over when using the spread operator.
// catch part is redacted
function customFetch(input: any, init: any) {
return globalThis.$fetch.raw(input.toString(), init)
.then((response) => {
return {
...response,
json: () => Promise.resolve(response._data),
}
});
}
I believe this is because the spread operator only deals with string based properties and response.headers is keyed as a Symbol.
Currently, I rectify this behavior by explicitly copying over the headers property:
// catch part is redacted
function customFetch(input: any, init: any) {
return globalThis.$fetch.raw(input.toString(), init)
.then((response) => {
return {
...response,
// explicitly copy over the headers
headers: response.headers,
json: () => Promise.resolve(response._data),
}
});
}
I am not sure if omitting the headers is by design or not (since there's opinion from the tRPC repo saying that tRPC does not care about the transport, so the only thing matters is the response body).
It seems the
customFetch
used in the customhttpLink
andhttpBatchLink
does not copy over the response headers. Consequently, response headers become undefined in links downstream.This is a snippet of the
customFetch
function, which adds the resolvedjson
to the response object. However,response.headers
is not copied over when using the spread operator.I believe this is because the spread operator only deals with string based properties and
response.headers
is keyed as aSymbol
.Currently, I rectify this behavior by explicitly copying over the
headers
property:I am not sure if omitting the headers is by design or not (since there's opinion from the tRPC repo saying that tRPC does not care about the transport, so the only thing matters is the response body).