mirror of
https://github.com/hanzoai/chat.git
synced 2026-09-30 20:51:17 +00:00
zeekayandHanzo Dev
41c39bf825
Three defects that met at the same place: a new visitor's first message failed,
and nothing on screen said why.
1. A gateway 402 rendered as "Something went wrong on our side".
Measured live: signed-in user, model `enso`, real message. The stored message
was `{"type":"error","error":"An error occurred while processing the request:
402 invalid API key"}` — prose. `Messages/Content/Error.tsx` dispatches on a
CODE, so a paywall read as an outage to someone holding a credit card.
The status was never lost upstream (langchain re-throws the OpenAI client's
`APIError` untouched for a 402, so `err.status === 402` is right there); it was
thrown away by the carriers. `server/utils/refusal.js` is now the ONE place
that names a failure — the thrower's code wins, else the status names it — and
both carriers use it: the agent run's error content part
(`controllers/agents/client.js`) and `handleAbortError`, which used to pass a
message through only when it happened to contain the substring `"type"`.
`middleware/error.js#sendResponse` no longer answers every failure with 500.
This is the rule `routes/ask.js#relayStatus` already applies to the answer
engine, and the shape `controllers/agents/request.js` already answers with.
Client side, `errorKey` now also reads an OpenAI-shaped nested body
(`{error:{code}}`), and `insufficient_quota` renders the add-credit action
instead of upstream's "set up your own API key" — there is no key to set on
hanzo.chat; the money lives at billing.hanzo.ai. The generic fallback stays
for failures that genuinely name nothing.
2. The mode selector opened on Search, which is sign-in gated.
Search relays to cloud `/v1/ask` and needs a real principal, so an anonymous
visitor's FIRST message was a 401 rendered as an inline error. Chat is the
guest-scoped preview, and when even that is refused its submit path opens the
login gate. It is also what the chips already say — `chat` is listed first.
3. The guest mint 429'd after a handful of page loads, then failed silently.
The client DISCARDED a live guest bearer on every page load and minted a fresh
one, so `guestTokenLimiter` was measuring page views rather than mint-spam —
and behind Cloudflare one CF-Connecting-IP can be a whole office. The token
already carries its own lifetime, so it is now reused for it (sessionStorage,
not localStorage: a bearer must not outlive the visit on a shared browser). A
visit costs one mint per expiry window instead of one per paint; the ceiling
itself is unchanged, because the number was never the fix.
And when the mint IS refused, say so. It used to pass in total silence —
`Root` fell through to the marketing page, so a 429 on an auxiliary token read
as a site with no composer and no explanation. `acquireGuest` now opens the
ONE login gate with a new reason, `unavailable`, and `Root` mounts that gate
alongside the landing. Because auth resolves before the shell paints, the gate
picks up a reason that landed while it was unmounted; reading consumes it, so
a dismissal is never undone by a remount.
Tests: api 2287 -> 2312 passing, client 1792 -> 1809 passing, 0 new failures
(pre-existing failures unchanged at 408 api / 503 client). Lint 893 -> 892
problems — one pre-existing prettier error fixed, none introduced.
Co-authored-by: Hanzo Dev <[email protected]>