Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generated type definitions should not include the error case #2046

Open
manuschillernordlb opened this issue Feb 22, 2024 · 3 comments
Open
Assignees

Comments

@manuschillernordlb
Copy link

Models generated with openapi-typescript-codegen contain the correctly inferred types from our OpenAPI Spec, but also the structure for the error object.

That should probably not be the case adds unnecessary of guarding code when calling the api functions.

Example:

const { data: favorites, isLoading } = useQuery({
    queryKey: ["favorites"],
    queryFn: async () => {
      const result = await api.getFavorites();

      if ("status" in result) throw new Error(result.title, { cause: result });

      return result.favorites;
    },
    initialData: () => [],
  });

It seems like the generated client should throw (and therefore not resolve) in any case when response.ok is not true:

if (!result.ok) {
const errorStatus = result.status ?? 'unknown';
const errorStatusText = result.statusText ?? 'unknown';
const errorBody = (() => {
try {
return JSON.stringify(result.body, null, 2);
} catch (e) {
return undefined;
}
})();
throw new ApiError(options, result,
`Generic Error: status: ${errorStatus}; status text: ${errorStatusText}; body: ${errorBody}`
);

@mrlubos
Copy link
Collaborator

mrlubos commented Feb 22, 2024

@manuschillernordlb can you share your OpenAPI spec and the generated vs expected type?

@awolden
Copy link

awolden commented Feb 24, 2024

+1 also running into this pattern where I have to type check responses for Error typing even though it never seems to get returned as an error, it's always a thrown error. Is this an issue with the open api definition or something we can configure?

Our response definition looks something like:

        "204":
          description: Successfully updated status for issue
        "422":
          description: Invalid Status Transition
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Error"
        "409":
          description: Unexpected Transition Result
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Error"
        "404":
          description: Issue not found
        "400":
          description: Malformed Request
        default:
          description: Unexpected Error
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Error"
                ```

@mrlubos
Copy link
Collaborator

mrlubos commented Mar 2, 2024

@awolden are you able to create a failing test case? I can look at it for you in our fork

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants