Regression in 7.4.1: TData generic breaks type check for custom mutation options function

[severinh]

What are the steps to reproduce this issue?

In our system, we use the mutationOptions Orval configuration to add a default error handler to all mutations to show an error snackbar in the product (unless overridden by the user of the mutation):

Config used

override: {
  query: {
    mutationOptions: {
      name: 'useDefaultOpenApiMutationOptions',
      path: 'src/common/hooks/useDefaultOpenApiOptions.ts',
    },
  }
}

useDefaultOpenApiOptions.ts contains the following:

/** Shows a default, generic error snack bar if the request fails. Callers can override this behavior. */
export const useDefaultOpenApiMutationOptions = <
  TData = unknown, // All unknown because this is function is used across all mutations.
  TError = unknown,
  TVariables = void,
  TContext = unknown,
>(
  mutationOptions: UseMutationOptions<TData, TError, TVariables, TContext>
): UseMutationOptions<TData, TError, TVariables, TContext> => {
  return {
    onError: (error) => {
      SnackbarUtils.error('Something went wrong');
    },
    ...mutationOptions,
  };
};

This worked well until 7.3.0. With the upgrade to 7.4.0, the code generated by Orval does not type-check anymore.

The error is:

Type 'MutationFunction<CreateOfferImportResponse, { roundId: string; data: SupplierUpdateOffersRequest; }>' is not assignable to type 'MutationFunction<TData, { roundId: string; data: SupplierUpdateOffersRequest; }>'.
  Type 'CreateOfferImportResponse' is not assignable to type 'TData'.
    'TData' could be instantiated with an arbitrary type which could be unrelated to 'CreateOfferImportResponse'.ts(2322)
types.d.ts(354, 5): The expected type comes from property 'mutationFn' which is declared here on type 'UseMutationOptions<TData, TError, { roundId: string; data: SupplierUpdateOffersRequest; }, TContext>'

The same type check error happens for all generated mutations.

Cause

The change that introduced this breakage is #1735.

The comment in that PR mentions that this is a breaking change, but it does not say how teams affected by the breakage could resolve the breakage.

Resolution?

I could not figure out how to update our custom mutation options function to make the type checking issue go away. It seems the problem is not our function, but rather the type inconsistency in the generated mutation itself between the mutationOptions variable (any TData allowed) and mutationFn (TData is the actual response type).

Could you tell me how I can make this type-check? Right now this blocks us from upgrading to Orval 7.4.0.

If it's not possible on our end, can we revert #1735? I personally don't understand why that PR was needed, and what value it brings to override the TData of a mutation.

What versions are you using?

  System:
    OS: macOS 14.6.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 405.61 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  npmPackages:
    @tanstack/react-query: 4.36.1 => 4.36.1 
    axios: 1.7.9 => 1.7.9 
    msw: 2.6.8 => 2.6.8 
    orval: 7.4.1 => 7.4.1 
    react: 18.3.1 => 18.3.1 
    zod: 3.23.8 => 3.23.8 

[melloware]

Can you try 7.4.1 i think this is fixed.

[severinh]

Can you try 7.4.1 i think this is fixed.

Thanks a lot for the quick reply! I'm afraid not. Both 7.4.0 and 7.4.1 have the same problem.

I've in the meantime I found a way to unblock the upgrade by dropping the type safety in the custom mutation options function. Something like the following:

/** Shows a default, generic error snack bar if the request fails. Callers can override this behavior. */
export const useDefaultOpenApiMutationOptions = <T>(mutationOptions: T): T => {
  const { t } = useTranslation();
  // The parameter has the type UseMutationOptions. However, using this type would cause the call
  // in the Orval-generated mutation code to not type-check due to https://github.com/orval-labs/orval/issues/1820.
  // Hence, for loosen the type safety of the method signature and cast.
  const typedMutationOptions = mutationOptions as UseMutationOptions;
  return {
    onError: (error: unknown) => {
      // Only display snackbar if error is not being caught by an error boundary.
      if (!typedMutationOptions.useErrorBoundary) {
        SnackbarUtils.error('Something went wrong');
      }
    },
    ...typedMutationOptions,
  } as T;
};

While this works, it's essentially a hack. I think other users of Orval will run into the same problem when trying to use custom mutation options functions, and will not know how to type them. Orval's documentation does not give an example of how to type such a function.

[oferitz-apex]

I think it's not just with override of mutation options but a more broad issue with override in general.
I'm using a mutator override with custom fetch:

And these new union with void types started to appear:

Which breaks the inference of the type where i want to use it:

[zdarovka]

I also think that since the 7.4 the support of partialOptions was broken. All of the queries now do not have the Partil options generated in the client

https://github.com/lentyaevpk/orval/blob/master/packages/query/src/index.ts#L501

[melloware]

@zdarovka did you try 7.4.1?

[zdarovka]

yes

[melloware]

OK I updated the title of the ticket to say 7.4.1

[soartec-lab]

I was thinking explicit typing would be preferable, but does that mean we lose type safety if we use custom mutations?
This is not what I intended, so I think I can revert #1735.

@lentyaevpk

What do you think?

[soartec-lab]

@severinh @oferitz-apex @zdarovka @melloware

Hey guys,
from @lentyaevpk No response, but I'm going to create a PR that reverts this. What do you all think?

[oferitz]

@soartec-lab In my specific case the union type with void is breaking the auto type inference, so if the revert will fix it i'm definitely support it.

[melloware]

Yep go ahead and revert it.

[soartec-lab]

@severinh @oferitz-apex @zdarovka @melloware

I reverted this by #1871 . A new version will be released soon, so please check back soon. Look forward to the new version.

@oferitz
Your issue may not be fixed by this solution. If the problem recurs in the next release, would you please open a new issue?