AbortController signal in nuxt with openapi-ts creates an error

[debloisg]

Description

Hi,
I'm trying to add an AbortController signal to a GET openapi endpoint. The function has been auto-generated with openapi-ts. It works fine when I'm trying to call it with a normal $fetch, but doesn't with the generated method.

// Working code
const results = await $fetch(`/search`, {
  method: 'GET',
  signal: abortController.signal,
  query: {
    // Query params
  },
})

// Not working code
const results = await searchSearchGet({
  path: {
    // Path params        
  },
  signal: abortController.signal,
  query: {
    // Query params
  },
  composable: '$fetch',
})

The resulting error is:

myfile.vue:xxx FetchError: [GET] "https://xxxxx.xxx/search": <no response> Failed to execute 'fetch' on 'Window': Failed to read the 'signal' property from 'RequestInit': Failed to convert value to 'AbortSignal'.

Do you have any idea ?

Reproducible example or configuration

No response

OpenAPI specification (optional)

      '@hey-api/nuxt':
        specifier: 0.2.1
        version: 0.2.1
      '@hey-api/openapi-ts':
        specifier: 0.83.1
        version: 0.83.1

System information (optional)

No response

[dosubot]

Hi @debloisg! I'm Dosu and I’m helping the openapi-ts team.

Passing AbortController.signal should work with openapi-ts generated methods when using composable: '$fetch', since the client is designed to accept any Nuxt/ofetch arguments, including signal docs. The error you’re seeing suggests the signal might be getting transformed or serialized incorrectly before reaching $fetch, so it’s not recognized as a valid AbortSignal docs.

To debug, check that abortController.signal is a real AbortSignal at runtime (e.g., console.log(abortController.signal instanceof AbortSignal) should be true). If it is, inspect how the generated method forwards the signal property—sometimes, generated clients might wrap or clone arguments in a way that breaks references.

As a workaround, you can use a request interceptor to inject the signal just before the request is sent docs, or configure a custom $fetch method via setConfig() to ensure proper signal handling docs. This can help if the default handling is problematic.

If you want to dig deeper, reviewing the generated code for searchSearchGet and how it handles the signal and composable options may reveal where the conversion issue happens.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[debloisg]

@dosu I went in the utils.gen.ts file and added make a console.log and a breakpoint on the following line:

export const executeFetchFn = (
  opts: Omit<Parameters<Client['request']>[0], 'composable'>,
  fetchFn: Required<Config>['$fetch'],
) => {
  const unwrappedOpts = unwrapRefs(opts);
  unwrappedOpts.rawBody = unwrappedOpts.body;
  unwrappedOpts.body = serializeBody(unwrappedOpts);
  console.log('Fetch options:', unwrappedOpts);
  return fetchFn(
    buildUrl(opts),
    // @ts-expect-error
    unwrappedOpts,
  );
};

and from what I could see it looked like the signal was correct at this stage.

[dosubot]

If the signal looks correct at the executeFetchFn stage, the issue might be happening after this point—possibly in how $fetch or ofetch receives or processes the options. Since the Nuxt client is designed to accept AbortController.signal as a direct argument when using composable: '$fetch' (docs), it's worth checking if unwrapRefs or serializeBody could be altering the signal reference (for example, by cloning or serializing the options object).

To narrow it down, you could try:

• Logging typeof and instanceof on unwrappedOpts.signal right before the fetchFn call to confirm it's still an AbortSignal.
• Using a request interceptor (docs) to log or validate the signal just before the request is sent.
• Testing a minimal call to executeFetchFn with $fetch and the signal directly, bypassing other layers, to see if the error persists.

If the signal is still valid at the last moment before $fetch, the problem may be with how $fetch or ofetch is being invoked or with the environment (e.g., SSR vs. client). If you find that the signal is no longer an AbortSignal at that point, then something in the generated client is transforming it. Let me know what you find!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[debloisg]

Indeed, unwrappedOpts.signal was not of type AbortSignal which is weird.

I fixed it with:

      onRequest: (context) => {
        context.options.signal = abortController.signal
      },

Which is a workaround, it should work without it.