Timeout configuration

[fungiboletus]

Hei, would it be possible to support configuring the timeout ?

[bfelbo]

Any updates on this? It would be great to have.

[ninnemannk]

I found after a bit of digging that the graphql-request library delegates additional options to the underlying node-fetch module. So, instantiating a client like so, delegates the timeout to the node-fetch library.

  const client = new GraphQLClient(config.url, {
    timeout: 30000,
    headers: {
      Authorization: `Bearer ${token}`
    }
  })

Delegation: https://github.com/prisma/graphql-request/blob/master/src/index.ts#L29
node-fetch options: https://www.npmjs.com/package/node-fetch#options

---

It would be fantastic to get this added to the documentation.

[prakhar241]

My IDE complains about using timeout being not defined -
https://github.com/prisma-labs/graphql-request/blob/master/src/types.ts#L7?

How to make it work?

[keithlayne]

@prakhar241 TS won't let you add excess properties when you pass an object literal. The solution is to construct the options as a separate const and then pass them in:

const options = { timeout: 30000, mode: 'cors' };
const graphQLClient = new GraphQLClient(requestURL, options);

[jescalan]

node-fetch has deprecated the timeout option in their latest release in favor of passing an AbortSignal. Unfortunately, passing this at the top level doesn't work correctly, as each request must have its own signal, and if the request was successful, the timeout on the signal must be cleared.

Unfortunately, this means we need to find another way to add a timeout option. I'd be happy to put up a PR to add it to this library if that's cool with the maintainers!

[jasonkuhrt]

@jescalan I'm not familiar with AbortSignal yet or how it could impact the graphql-request API. Could you start a new issue to show and discuss the design further? Once we have a some better understanding around the implications then I can better tell you if the PR is safe to start or not (safe meaning: will the work be wasted).

[naruaway]

For people who found this issue to look for how to implement timeout for graphql-request:

Since graphql-request supports custom fetch like the above, we can easily add global timeout option without changing code of graphql-request with the following helper:

const createFetchWithTimeout = (timeout: number) => async (
    input: RequestInfo,
    init?: RequestInit
) => {
    if (init.signal) {
        throw new Error(
            "it looks like graphql-request started using AbortSignal on its own. Please check graphql-request's recent updates"
        );
    }

    const controller = new AbortController();

    const timerId = setTimeout(() => {
        controller.abort();
    }, timeout);

    try {
        return await fetch(input, { ...init, signal: controller.signal });
    } finally {
        clearTimeout(timerId);
    }
};

Then we can use it like the following:

const client = new GraphQLClient(YOUR_API_ENDPOINT, {
    // 2000ms timeout
    fetch: createFetchWithTimeout(2000),
});

[yhou2021]

If your project is using TypeScript, the solution above will need to add URL as an alternative type of input, like this:

const createFetchWithTimeout =
  (timeout?: number) =>
  async (input: RequestInfo | URL, init?: RequestInit)

Otherwise TS compiler would complain that RestquestInfo is not assignable to RequestInfo | URL.

[dmitry-zaporozhan]

Shorter version:

fetch(input, { ...init, signal: AbortSignal.timeout(timeout) })

[WtfJoke]

If you are running in nodejs this does the trick:

return new GraphQLClient(someUrl, {
    signal: AbortSignal.timeout(API_CALL_TIMEOUT_MS),
});

See AbortSignal-Docs