Repository navigation
fix(api): small handler bugs found while documenting the API (#262) #1102
Description
Found while documenting the API in #262 (PR #1100). These are code bugs, not spec gaps, so they were left out of that PR:
- Analytics validation: an unsupported analytics
intervalordimensionvalue returns 500 instead of 400. - Registration approval: approving a registration can leave it approved with no cloud account when the account creation fails afterwards. It isn't atomic.
- Account update:
PUT /api/accounts/{id}doesn't saveprovider. - Email revoke form: its POST always gets 401.
- Azure revokes: these probably return 500. This is unverified.
Each needs its own small fix and test; split this issue if that's easier to track.
Activity
IAmJSD commentedon Oct 19, 2026
Claiming: working on this
IAmJSD commentedon Oct 27, 2026
Status update (2026-10-27, checked against main at 7b86e38): Waiting on an owner decision.
Items 1, 2, 3 and 5 (analytics 400, atomic registration approval, refusing a provider change, Azure revoke 22P02 to 404) are fixed in draft #1141. That PR is held on D14 (a real Azure sandbox revoke before merge) and now conflicts with main. None of these fixes are on main. Item 4 (the email revoke form's POST always gets 401) is not fixed anywhere and needs an owner decision.
Left / blocked on: Items 1-3 and 5: held PR #1141, waiting on D14. Item 4: owner decision. Should the email revoke link get token-only authorization, which widens the auth model, or point to a frontend /purchases/revoke/:id deep link that uses the session, like approve and cancel? Recommendation: the deep link, which keeps session auth and matches approve/cancel. It needs cristim's frontend route, then a small backend change to the email link and the public form at internal/api/handler_purchases.go:1908 and router.go:175-176.
fix(api): four handler bugs found while documenting the API (#1102) (#…