fix(membership): surface checkout errors as a flash banner (BUNYIP-187) #211
No reviewers
Labels
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
psa-systems/bunyip!211
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/BUNYIP-187-surface-checkout-errors"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The Subscribe button on
/membershipwas a silent failure surface:bunyip-web/src/handlers/dashboard.rs::membership_subscribematched theapi response with a
_ => redirect_cookies("/membership", ...)arm thatswallowed every error - a 400 / 5xx / network drop landed the user back
on the page with NO indication of what went wrong. The api's actual
error (e.g.
price_id: No active price configured, the silent-400gotcha catalogued as gotcha 3 in BUNYIP-A-5) was being thrown away.
What landed:
membership_subscribenow captures thecalls::checkoutresult. OnErr(e)it redirects to/membership?error=<urlenc(e.user_message())>;on
Okwith a non-Stripe URL it redirects with a "Checkout returnedan invalid URL" message. Only the real
https://checkout.stripe.com/URL still 302s straight to Stripe (unchanged happy path).
New
humanise_checkout_errormaps the two known raw messages frombunyip-api/src/handlers/membership.rs("No active price configured","Stripe is not configured") to operator-actionable copy that points
at the configuration step. Unknown messages pass through verbatim so
the operator still gets useful information instead of a sanitised
wall.
New
MembershipQuery { ok, error }plumbed into themembershipGEThandler (mirrors the existing
SettingsQueryshape). The pagerenders the flash banner above the existing
past_duewarning usingthe same
error_box+clamp_msgprimitives the settings pagealready uses, so the visual treatment is consistent.
This is the user-visible symptom behind BUNYIP-170 ("Subscribe button
doesnt work in production"); closing this ticket lets BUNYIP-170 close
as a duplicate.
#BUNYIP-187
The Subscribe button on `/membership` was a silent failure surface: `bunyip-web/src/handlers/dashboard.rs::membership_subscribe` matched the api response with a `_ => redirect_cookies("/membership", ...)` arm that swallowed every error - a 400 / 5xx / network drop landed the user back on the page with NO indication of what went wrong. The api's actual error (e.g. `price_id: No active price configured`, the silent-400 gotcha catalogued as gotcha 3 in BUNYIP-A-5) was being thrown away. What landed: * `membership_subscribe` now captures the `calls::checkout` result. On `Err(e)` it redirects to `/membership?error=<urlenc(e.user_message())>`; on `Ok` with a non-Stripe URL it redirects with a "Checkout returned an invalid URL" message. Only the real `https://checkout.stripe.com/` URL still 302s straight to Stripe (unchanged happy path). * New `humanise_checkout_error` maps the two known raw messages from `bunyip-api/src/handlers/membership.rs` ("No active price configured", "Stripe is not configured") to operator-actionable copy that points at the configuration step. Unknown messages pass through verbatim so the operator still gets useful information instead of a sanitised wall. * New `MembershipQuery { ok, error }` plumbed into the `membership` GET handler (mirrors the existing `SettingsQuery` shape). The page renders the flash banner above the existing `past_due` warning using the same `error_box` + `clamp_msg` primitives the settings page already uses, so the visual treatment is consistent. This is the user-visible symptom behind BUNYIP-170 ("Subscribe button doesnt work in production"); closing this ticket lets BUNYIP-170 close as a duplicate. #BUNYIP-187