Fix invalid data check in query/mutation fn

[HugeLetters]

Changes

Closes #1973

How to Review

Checklist

• Unit tests updated
• docs/ updated (if necessary)
• pnpm run update:examples run (only applicable for openapi-typescript)

[changeset-bot]

🦋 Changeset detected

Latest commit: 204d5fd

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
openapi-react-query	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[kerwanp]

Thanks, could you please provide a test case as well as a patch commit?

[HugeLetters]

After working on tests it got me thinking - should we even check if data is undefined?
Perhaps just an if(error) check would be sufficient?

Because the problem is

• if we throw when data is undefined, we just throw undefined as error(cause error is undefined too)
• react query already handles returning undefined as an error and will throw accordingly - perhaps it should just remain their responsibility

I would suggest doing this with a comment that we can safely return undefined since react-query itself will throw an error

if (error) {
    throw error;
}

if (data === undefined) {
    return data as never;
}

upd: its a bit complicated with mutationFn tho since undefined is actually allowed as a return value there 🫠
I guess we could return our own custom error here? we should be fine since undefined is invalid json so we cant receive it under normal circumstance

[kerwanp]

I do not exactly remember why we checked for that data in the first place. But maybe yes we could just remove this check as we need to handle responses with no content anyway (see #1973 (comment)).

[kerwanp]

I'm ok with the implementation, thanks for the work. Before we merge can you just double check that we cant return undefined because of tanstack query and not because our types are wrong?

And take the opportunity to add your github in the contributors list

[HugeLetters]

shouldn't matter since the type is dictated by return type of createClient anyway, its not inferred from here - just checked that what we return is valid

[kerwanp]

Looks good to me! Good series of tests as well, thanks for taking the time.