hungryroot/jira/be_7138_fix_ingredient_credits_type_mismatch_between_openapi_spec_and_endpoint_get_api_v3_pairings.org

BE-7138 Fix ingredient_credits type mismatch between OpenAPI spec and endpoint GET /api/v3/pairings/

Description

The TypeScript client type for ingredient_credits on the pairings ingredients

expansion does not match the OpenAPI spec, creating a contract mismatch that

could surprise future consumers.

Problem

The OpenAPI spec for GET /api/v3/pairings/ defines ingredient_credits as:

Type: number

Format: double

Required: yes (when expand=ingredients is used)

However, the TypeScript client types this field as string? (optional string).

This is not a runtime issue today because the current usage in transforms.ts

wraps the value with Number(ingredient.ingredient_credits), which coerces both

strings and numbers correctly. But the mismatch means:

Future consumers reading the TypeScript types will assume the field is an

optional string, not a required number.

Code generation tools that rely on the TypeScript types (rather than the OpenAPI

spec) will propagate the incorrect type.

Type safety is weakened -- TypeScript won't catch cases where the value is used

directly without Number() coercion.

Expected Fix

Update the TypeScript type definition for ingredient_credits to match the

OpenAPI spec:

Change the type from string? (optional string) to number (required number)

Audit usages of ingredient_credits across the frontend codebase to confirm they

are compatible with the corrected type (the Number() wrapper in transforms.ts

would become a no-op but is harmless to leave)

Remove any unnecessary Number() coercions if desired, or leave them as defensive

coding

Acceptance Criteria

[ ] ingredient_credits TypeScript type matches the OpenAPI spec (number,

required)

[ ] All existing usages compile cleanly with the updated type

[ ] No runtime behavior changes (this should be a types-only fix)