Allow access to request headers in onError

[thibmaek]

I love RQ, but I'm having a particularly difficult time trying to get it to work together with a transaction ID header we use to facilitate Distributed Tracing.

I have a zustand store called useErrorStore which takes care of showing a red alert in the app but also send that to Sentry which we use for monitoring.

const useErrorStore = create(set => ({
  currentError: null,
  setError: err => {
    logger.warn('Received a new error on the stack:', err.error);
    set({ currentError: err });

    // This is our service which tracks to Sentry
    Tracing.traceException(err.error, { transactionID: err.transactionID });
  },
}));

Trying to retrieve this transaction ID (a UUIDv4) was already but I managed to create a withDefaultHeaders function which will just return an object containing that transaction ID header. The hard part is now that I want to access it from the request executed by RQ when that errors:

import { useDataQuery } from './codegen.gql.ts';

export default function useData() {
  const { graphQLClient, withDefaultHeaders } = useGraphQLClient();
  const { setError } = useErrorStore();

  // This is generated by graphql-codegen
  useDataQuery(
    graphQLClient,
    undefined,
    {
      onError: error => {
        // This doesn't exist but would be greatly appreciated 🙏
        const transactionID = error.request.headers['x-transaction-id'];

        setError({ error, retryAction: refetch, transactionID });
      },
    },
    withDefaultHeaders(),
  );

Anybody here faced a similar scenario? Found a solution? Does this seem like a good suggestion? Other approaches?

[TkDodo]

we have an onError callback, which gets passed the error, which might or might not contain the request headers, that depends on your transport layer. I don't see why the code you posted shouldn't work ?

[thibmaek]

The headers property is missing from the error.request object. I'd expect (just like a browser request or a Fastify/Express request) that the request contains all relevant info (headers, user-agent etc.) that's being made to the endpoint.

Only two properties seem to exist on error.response: data & variables, those only relate to the request body itself.

[TkDodo]

okay but that is not react-query's responsibility, as it doesn't make the api call and it also doesn't produce the actual error.

Like, if you are using axios for data fetching, the error will be of type AxiosError, which contains the whole request + response:

export interface AxiosError<T = any, D = any> extends Error {
  config: AxiosRequestConfig<D>;
  code?: string;
  request?: any;
  response?: AxiosResponse<T, D>;
  isAxiosError: boolean;
  toJSON: () => object;
}

if your queryFn just returns Promise.reject(new Error("foo")) , it will be just an error with the message foo.

I would look further at your graphQLClient.

[thibmaek]

Aha! That's insightful. I come from different libraries like Apollo that work a bit different so lost concept of how RQ works here for a second. Thanks!

[thibmaek]

For anyone else stumbling across this: I've got a PR open to return request headers in graphql-request error responses: graffle-js/graffle#329