TypeScript SDK generated by oazapfts (FastAPI OpenAPI codegen) types each function's response as a discriminated union over the status codes declared in the OpenAPI schema, e.g. { status: 200, data: T } | { status: 422, data: HttpValidationError }. When the backend also returns 400 from a custom HTTPException subclass that wasn't declared in the schema, TypeScript errors with This comparison appears to be unintentional because the types '422' and '400' have no overlap on response.status === 400. The runtime 400 still arrives; only the type narrowing rejects the literal check.
Two paths:
Fix the schema (preferred long-term): declare the 400 response in the FastAPI route via responses={400: {'model': ErrorResponseOVO}} or by registering the custom exception class globally so OpenAPI advertises it. Regenerate the SDK and the literal check type-checks.
Cast for the immediate fix: (response.status as number) === 400. oazapfts uses literal types specifically for narrowing response.data, so casting only the status side leaves the rest of the SDK's type safety intact. Leave a comment so the next reader knows it's a documented gap, not a typo:
// SDK only enumerates 200 | 422 but backend returns 400 from InvalidParameter.
if ((response.status as number) === 400 || response.status === 422) { ... }Same issue affects any OpenAPI codegen with literal-typed status unions: hey-api/openapi-ts, openapi-typescript-codegen, etc.