You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
importcreateFetchClientfrom"openapi-fetch";importcreateClientfrom"openapi-react-query";importtype{paths}from"./api.schema.gen.js";// generated by openapi-typescriptconstfetchClient=createFetchClient<paths>({baseUrl: "https://myapi.dev/v1/",});const$api=createClient(fetchClient);constMyComponent=()=>{const{ data, error, isLoading }=$api.useQuery("get","/projects/id={projectId}",{params: {path: {projectId: "fake-uuid"},},},);if(isLoading||!data)return"Loading...";if(error)return`An error occured: ${error.message}`;// !! Property 'message' does not exist on type 'never'. ts(2339)return<div>{data.title}</div>;};
And the editor hover-over indicates error is null | undefined, so the error makes sense:
The null arrives from react-query itself, but the undefined is a problem, and it also appears in both the onError callback and error state of mutations as only undefined.
For reference, here is the underlying path from openapi.yaml, as generated by @nestjs/swagger:
paths:
# .../projects/id={projectId}:
get:
description: Gets a project by its IDoperationId: ProjectsByIdController_getparameters:
- name: projectIdrequired: truein: pathdescription: The project IDschema:
format: uuidtype: stringresponses:
"200":
description: The projectcontent:
application/json:
schema:
$ref: "#/components/schemas/ProjectModel""403": &a3description: User is not authorized to perform this action."404": &a4description: The project requested could not be found.summary: ""tags: &a5
- projects
My thoughts as to possible sources of the error are:
The types UseMutationMethod, UseQueryMethod, etc. get the error via the generic Response["error"], but Response is a FetchResponse, which is a union type, and only the first member of the union is extracted (which is undefined | never and the never gets dropped by TS). Based on TypeScript 5.8.Edit: Never mind this, fairly confident it's the next thing.
The ErrorResponse and GetResponseContent from openapi-typescript-helpers expected a content block to be present on the error and ignores errors which do not have them.
Regardless of which of the two is correct, other errors not present in the schema can still occur, such as undocumented responses (mainly 5xx) or network errors. IMO, the error type should at least always include Error to indicate otherwise-undocumented errors (who's to say a TypeError or deserialization errors won't appear?), or just become unknown as is usually the case in JS.
Edit: This following yarn patch alleviates the problem by introducing Error as suggested and gets things working again.
Uh oh!
There was an error while loading. Please reload this page.
openapi-react-query version
0.5.0
Description
The error types for all query/mutation methods, including
queryOptions
, is inferred incorrectly and always results inundefined
(ornull | undefined
).The example provided in the documentation, therefor, does not work.
Copied from https://openapi-ts.dev/openapi-react-query/#basic-usage and modified only to attach it to my generated openapi schema (which was generated by
openapi-typescript
).And the editor hover-over indicates

error
isnull | undefined
, so the error makes sense:The
null
arrives fromreact-query
itself, but theundefined
is a problem, and it also appears in both theonError
callback anderror
state of mutations as onlyundefined
.For reference, here is the underlying path from
openapi.yaml
, as generated by@nestjs/swagger
:My thoughts as to possible sources of the error are:
The typesEdit: Never mind this, fairly confident it's the next thing.UseMutationMethod
,UseQueryMethod
, etc. get the error via the genericResponse["error"]
, butResponse
is aFetchResponse
, which is a union type, and only the first member of the union is extracted (which isundefined | never
and thenever
gets dropped by TS). Based on TypeScript 5.8.ErrorResponse
andGetResponseContent
fromopenapi-typescript-helpers
expected acontent
block to be present on the error and ignores errors which do not have them.Regardless of which of the two is correct, other errors not present in the schema can still occur, such as undocumented responses (mainly 5xx) or network errors. IMO, the error type should at least always include
Error
to indicate otherwise-undocumented errors (who's to say aTypeError
or deserialization errors won't appear?), or just becomeunknown
as is usually the case in JS.Edit: This following yarn patch alleviates the problem by introducing
Error
as suggested and gets things working again.openapi-fetch-npm-0.14.0-20e667e085.patch
Reproduction
The snippets above reproduce the error when copy & pasted in under TypeScript 5.8.
Expected result
The error does not appear, as documented.
Extra
The text was updated successfully, but these errors were encountered: