feat(gateway): code and report a refused mint - #1222
Conversation
🧙 Wizard CIRun the Wizard CI and test your changes against wizard-workbench example apps by replying with a GitHub comment using one of the following commands: Test all apps:
Test all apps in a directory:
Test an individual app:
Show more apps
Test against a Context Mill branch:
Add Results will be posted here when complete. |
ebe3b05 to
0b01601
Compare
0b01601 to
6aa520c
Compare
gewenyu99
left a comment
There was a problem hiding this comment.
Okay hot take, prob doesn't matter. If we log mint refuse reason on the server with session attached, there is no reason to even send it to the client. They don't need to know if it's not actionable. For mint refuses, we gotta think about this.
Anything related to hitting limit and with an actionable please try again in time is fine. Anything else basically don't bother
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
typeof body.code === 'string' is true for the empty string, so a refusal carrying both keys lost its outcome whenever the code cleaned to nothing. The catalog doc gains the group this PR adds, and the precedence has fixtures that carry one key each, so swapping the arms goes red. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
6aa520c to
eb9e605
Compare
Problem
A refused mint reaches the user as "Something went wrong", and nothing records that it happened, so the refusals this stack adds server-side are invisible from the client.
Changes
The refusal gets a code, a message, and an event.
gatewayerror group withGatewayMintRefusedandGatewayMintFailed; the refusal carries its status and outcome so the abort path resolves it instead of the generic unhandled code.gateway mint refusedis captured with status, outcome and program.codefirst, thenoutcome: the server's exception layer flattens a dict detail, so that is where the machine-readable value lands. Acodethat cleans to nothing does not shadow a usableoutcome.Test plan
pnpm test. Precedence is pinned by fixtures carrying one key each, plus the empty and control-only cases; the degraded bodies (non-JSON, empty, neither key, oversized, non-string) each have a case.