mirror of
https://github.com/getpaseo/paseo.git
synced 2026-10-27 19:52:49 +00:00
paseo-bot[bot]andMatteo Pietro Dazzi
3054f80050
### Linked issue Closes #5247 ### Type of change - [x] Bug fix - [ ] New feature - [ ] Enhancement - [ ] Refactor - [ ] Docs ### Reasoning A user whose MiniMax account has no active token plan opened the Usage page and saw a red **Error** badge on the MiniMax card with a block of raw JSON as its body: `[{"expected":"array","code":"invalid_type","path":["model_remains"],...}]`. MiniMax reports application-level failures inside an HTTP 200 body — `base_resp.status_code` is non-zero and `model_remains` comes back as `null`. Two things went wrong with that response: - `MiniMaxQuotaResponseSchema` declared `model_remains` as `z.array(...).optional()`, which admits a *missing* key but not `null`, so `.parse()` threw on a perfectly ordinary no-subscription response. - `fetchUsage()` only checked `res.ok`, so an API-level error returned with HTTP 200 was never inspected in the first place. The rejection propagated to `ProviderUsageService`, which stores `reason.message` as the card's error text. For a `ZodError`, that message *is* the serialized issue list — which is how the JSON blob reached the card. This accepts `null` for `model_remains`, parses `base_resp`, and returns the plain unavailable result when the status code is non-zero, matching how a failed HTTP response is already handled in the same method. The API's own `status_msg` goes to the debug log rather than to the card: an account without a token plan is a normal state, not an error, so it should read as "Unavailable" like an unconfigured provider does — not as a red Error. ### Goals - A MiniMax account with no active token plan renders as **Unavailable** with no error text. - `model_remains: null` is accepted wherever it appears, with or without a `base_resp`. - Application-level errors carried in an HTTP 200 body are detected rather than treated as success. - Accounts that do have a plan keep rendering their interval and weekly windows unchanged. ### Non-goals - **Generic error rendering in the Usage card.** The issue also asks that structured errors (ZodError and friends) be mapped to a concise message in the UI. That changes what every provider's card shows on schema drift, so it is a design decision for the maintainer rather than part of this fix. With the producer corrected, no ZodError arises on this path; if another provider's response shape drifts, raw issue JSON can still reach the card. Left open for the maintainer. - Surfacing MiniMax's `status_msg` in the UI. It is logged at debug instead, so the card does not turn red for a normal no-subscription account. ### QA Reproduced and verified through the real `ProviderUsageService` with the exact payload from the report, in `packages/server/src/services/quota-fetcher/service.test.ts`. **Before** — `reports MiniMax accounts with no active token plan as unavailable` fails, and the failure output is the reported symptom verbatim: ``` - Expected + Received - "status": "unavailable", + "status": "error", - "error": null, + "error": "[ + { + \"expected\": \"array\", + \"code\": \"invalid_type\", + \"path\": [ \"model_remains\" ], + \"message\": \"Invalid input: expected array, received null\" + } + ]", ``` **After** — the full quota-fetcher suite passes: `Tests 71 passed (71)`. Three tests were added, two of which are red without the provider change (confirmed by stashing only `minimax.ts`): - `reports MiniMax accounts with no active token plan as unavailable` — the reported response (`model_remains: null` + `base_resp` 2062) → `status: "unavailable"`, `error: null`. - `reports a null MiniMax token plan as unavailable even without base_resp` — `model_remains: null` alone. - `still reads MiniMax windows when base_resp reports success` — guards against the new status check rejecting healthy accounts. Also run locally: `npm run typecheck --workspace=@getpaseo/server`, `npx oxlint packages/server/src/services/quota-fetcher/`, `npx oxfmt --check packages/server/src/services/quota-fetcher/` — all clean. No UI change, so no screenshots: with the provider fixed, the card takes its existing "Unavailable" rendering, the same one an unconfigured provider already gets. ### Checklist - [x] Plugin changes follow the SDK import boundaries (if applicable) - [x] One focused change - [x] `npm run typecheck` passes - [x] `npm run lint` passes - [x] `npm run format` passes - [x] QA evidence - [x] Tests added or updated where it made sense ## Supersedes - [PR #5252 — fix(quota): handle MiniMax accounts with no active token plan (#5247)](https://github.com/getpaseo/paseo/pull/5252) — Same diagnosis and same reported workflow. That PR returns `status: "error"` carrying MiniMax's `status_msg`, which keeps the red Error badge on the card for an account that is simply unsubscribed; this branch returns the plain unavailable result the issue asks for. It also adds cross-provider `ZodError` summarizing in `ProviderUsageService`, which is the design decision left as a non-goal above. Co-authored-by: Matteo Pietro Dazzi <ilteoood@gmail.com>