Upgrading to 0.10.0 results in Failed to execute 'fetch' on 'Window'

[cmcnicholas]

Upgrading to 0.10.0 results in Failed to execute 'fetch' on 'Window'

[yethee]

I think the reason for the error is that an instance of Request is passed to fetch() as the second argument, instead of a plain object.

[hauk88]

Hi. I ran into this while doing some testing of this lib. I have a small repo that reproduces the error:
https://github.com/hauk88/e2e-typesafe/tree/openapi-fetch-bug. The related code is in open-api/fe/src/App.tsx

It is not really refined and a bit hacked toghether with conda environments etc, so not the perfect repo to look at maybe, but I though I would leave it here anyway.

If you manage to run the backend (open-api/be/) and the frontend (open-api/fe/) it should reproduce the error in the console if you press the send button in the UI.

[drwpow]

Edit: sorry; replied to wrong issue.

[drwpow]

Could you provide a reproduction of this and give more information about what environment you’re fetching in (browser? node? deno?)? The tests are currently passing, and I’m not able to replicate it myself. I believe you’re having the issue, but not sure what hole our test suite has that needs to be filled.

[cmcnicholas]

Could you provide a reproduction of this and give more information about what environment you’re fetching in (browser? node? deno?)? The tests are currently passing, and I’m not able to replicate it myself. I believe you’re having the issue, but not sure what hole our test suite has that needs to be filled.

Hi, I don't have a repro currently but can look to put something together.

This is an NX monorepo with apps in a browser environment.

The only piece of middleware I have is:

{
    onRequest: (req) => {
      // add authentication
      req.headers.set('Authorization', `Bearer ${accessToken}`);

      // incorrectly sets headers for GET requests
      // https://github.com/drwpow/openapi-typescript/issues/1410
      if (req.method === 'GET' || req.method === 'DELETE') {
        req.headers.delete('Content-Type');
      }

      return req;
    },
  }

which after the update I have altered to this inline with the docs.

{
    onRequest: ({ request }) => {
      // add authentication
      request.headers.set('Authorization', `Bearer ${accessToken}`);

      // incorrectly sets headers for GET requests
      // https://github.com/drwpow/openapi-typescript/issues/1410
      if (request.method === 'GET' || request.method === 'DELETE') {
        request.headers.delete('Content-Type');
      }

      return request;
    },
  }

The rest is all pretty standard stuff:

const client = createClient<paths>({
  baseUrl,
});

await client.POST('/api/organisations/', { body: { name }, });

It never invokes a request and fails in the openapi-fetch library.

[cmcnicholas]

I've since put a breakpoint in the openapi-fetch.js implementation of coreFetch and traced this through to the invocation of fetch.

If I supplement the request variable with request.duplex = 'half' then it progresses and works as before. Has the creation of Request changed?

[lukasbash]

Same issue here. The weird part is that (at least in my case) it only happens when executing E2E tests with playwright and happy-dom. In the console trace of the now failing tests I find the same error:

TypeError: Failed to execute 'fetch' on 'Window': The `duplex` member must be specified for a request with a streaming body

[benyaminbeyzaie]

I'm also facing this issue

[drwpow]

Thank you all! Will push a fix to this later today. This also gives me enough info to see what needs to be added to the test suites to prevent this from happening again.

[drwpow]

I think the reason for the error is that an instance of Request is passed to fetch() as the second argument, instead of a plain object.

Ah that’s it exactly. This change was to improve support for third-party custom fetchers, such as #1691, but it’s a flawed implementation and this currently doesn’t match the fetch spec. Will improve this handling so that it both matches the official fetch spec, and is also friendly to third-party fetch clients that aren’t technically spec-compliant but are close.

[drwpow]

Also digging through other instances of this error, this seems to be an issue specific to Chrome/Chromium which made it difficult to catch 😅 (technically our tests run in Node.js, not Chromium). Safari has a different-but-related error, and in Firefox this Just Works™.

Anyway, wanted to dig further into the root issue before I understood the best fix to take (and I believe actual headless Playwright tests are the best thing to add here, rather than try and hack together Chrome and Safari tests in Node.js which are moving targets to say the least)