You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(api): small handler bugs found while documenting the API (#262) #1102
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 interval or dimension value 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 save provider.
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.
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.
Triaged (p2, as labelled). Five independent small handler bugs; each can land as its own PR with a test, starting with the non-atomic registration approval (item 2) and the provider not saved on account update (item 3).
Checked against main d79a1b8: items 1, 2, 3 and 5 are on main via #1141 (merged 7ec9b07, 2026-10-28); the earlier note that it is a held draft is stale. Item 4 (email revoke form POST 401) remains. Taking the recommended default: the email link opens a frontend /purchases/revoke/:id route that uses the session, like approve and cancel. Claimed by claude-platform-2.
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) (#…
cristim commentedon Nov 5, 2026
Triaged (p2, as labelled). Five independent small handler bugs; each can land as its own PR with a test, starting with the non-atomic registration approval (item 2) and the provider not saved on account update (item 3).
cristim commentedon Nov 11, 2026
Claimed by claude-platform-2.
cristim commentedon Nov 11, 2026
Checked against main d79a1b8: items 1, 2, 3 and 5 are on main via #1141 (merged 7ec9b07, 2026-10-28); the earlier note that it is a held draft is stale. Item 4 (email revoke form POST 401) remains. Taking the recommended default: the email link opens a frontend /purchases/revoke/:id route that uses the session, like approve and cancel. Claimed by claude-platform-2.