drwpow
Custom fetch options are stripped from the request. Next.js cache doesn't work properly.
Description
Openapi-fetch uses a request object for its fetch. https://github.com/drwpow/openapi-typescript/blob/9c277fb0a10c3513de46765a4381ccb722a72af4/packages/openapi-fetch/src/index.js#L101 The request object created by openapi-fetch strips away non standard fetch options, i.e. how Next.js passes its cache related params:
{ next: { revalidate: 3600 } }
More info on Next.js fetching data + caching
Reproduction
Try to pass next cache params in https://github.com/drwpow/openapi-typescript/blob/main/packages/openapi-fetch/examples/nextjs/app/page.tsx It won't change its behaviour, it always falls back to defaults, because the non standard ones are stripped away.
I've tried
I changed this line https://github.com/drwpow/openapi-typescript/blob/9c277fb0a10c3513de46765a4381ccb722a72af4/packages/openapi-fetch/src/index.js#L101
to
let response = await fetch(request, requestInit);
and it works, but I don't know if it would cause other problems.
Ah, hm. I was somewhat afraid this would happen, and did see it come up in one other test failure, but had thought it was fixed.
Would gladly welcome any PRs for this! This should be a fairly-straightforward issue to write a failing test for, and find a fix.
For the workaround, this could be ok as well as the cache mechanism, regardless a little wired.
const res = await client.GET("/api/v1/space", {
fetch: (request: unknown) => {
return fetch(request as Request, { next: { revalidate: 40 } } )
}
})
I have tested it in Next.js 14
Hi, i'm still facing this issue on some Next.js 14 routes after using the latest openapi-fetch release, especially when using with Next-Auth v5 which might be meddling with the edge runtime, where some features are limited. Either way, the issue i am facing in particular is when mutating (POST, PATCH) on my server, the body seems to be stripped, but GET is working fine. This https://github.com/drwpow/openapi-typescript/issues/1569#issuecomment-1982247959 is the only way the i've been able to fix it and have data received by the server, thanks @JE-lee ! Note: each of these mutation API calls are currently working fine with pure fetch, i'm in the process of migrating to this package, currently running into this obscure issue.
I'm just looking for clues here and I assume the problem is linked to this issue, whereby something Next-related isn't being or can't be passed through. Any help or guidance of what to investigate further would be much appreciated.
In the interim, is there a way to apply the custom fetch argument in a DRY manner, similar to how we can apply middleware? In the event that i have to add this to all my mutations
My $0.02 having been bit by and consequently moved away from Next.js. This is a problem with Next.js' API design rather than openapi-ts. Overloading and modifying the native fetch API is an utterly insane way to implement core features of a framework. My suggestion would be to file this issue with Next.js.
