A plan change the console refuses on purpose is logged at ERROR, like a fault #303

Open
opened 2026-10-30 22:51:33 +00:00 by cgalo5758 · 0 comments
Owner

What happens

A member's plan change (a switch, its preview, a cancel, a resume or a keep) can be refused for reasons the console expects: the target product is no longer published for members, the price is retired, the plan is suspended or paused, the member already holds that tier. Every one of these refusals reaches renderPlansAfterMove, which logs any error it is given at ERROR as "plan move failed" before choosing the message to show (internal/server/member_plan_moves.go:421-422). Its own switch then lists the refusals it knows, each with a message for the member (:423-441); only the default branch (:442-443) is an error the console did not expect.

The refusal has usually been logged once already at INFO where it was decided, for example "switch refused: product not published for members" (member_plan_moves.go:377-378) or "switch refused: the offer decision does not offer it" (internal/server/plan_offer.go:619-620, and :526, :531, :605). So one refusal writes an INFO line and an ERROR line. Checkout refuses the same kinds of target and logs them at INFO only (internal/server/billing.go:82, :249, :320).

What should happen

A refusal the code names is logged below ERROR, as checkout's are, and ERROR is kept for the errors it does not recognise: the default branch, and the failed reads that switchOfferFor and switchOffer wrap and return (plan_offer.go:535, :574-595).

Where

internal/server/member_plan_moves.go:419-443

Steps

  1. As an operator, take a product out of the member catalog while a member has the Products page open with a switch to it offered.
  2. As that member, press the switch button. The dialog closes and the page says the plan is no longer available.
  3. The console's log shows switch refused: product not published for members at INFO, then plan move failed with action=switch-preview at ERROR.

Why it matters

An operator who alerts on ERROR lines, or reads them to find faults, is sent to look at members doing ordinary things, and real faults in the same function are harder to pick out.

### What happens A member's plan change (a switch, its preview, a cancel, a resume or a keep) can be refused for reasons the console expects: the target product is no longer published for members, the price is retired, the plan is suspended or paused, the member already holds that tier. Every one of these refusals reaches `renderPlansAfterMove`, which logs any error it is given at ERROR as "plan move failed" before choosing the message to show (`internal/server/member_plan_moves.go:421-422`). Its own `switch` then lists the refusals it knows, each with a message for the member (`:423-441`); only the `default` branch (`:442-443`) is an error the console did not expect. The refusal has usually been logged once already at INFO where it was decided, for example "switch refused: product not published for members" (`member_plan_moves.go:377-378`) or "switch refused: the offer decision does not offer it" (`internal/server/plan_offer.go:619-620`, and `:526`, `:531`, `:605`). So one refusal writes an INFO line and an ERROR line. Checkout refuses the same kinds of target and logs them at INFO only (`internal/server/billing.go:82`, `:249`, `:320`). ### What should happen A refusal the code names is logged below ERROR, as checkout's are, and ERROR is kept for the errors it does not recognise: the `default` branch, and the failed reads that `switchOfferFor` and `switchOffer` wrap and return (`plan_offer.go:535`, `:574-595`). ### Where `internal/server/member_plan_moves.go:419-443` ### Steps 1. As an operator, take a product out of the member catalog while a member has the Products page open with a switch to it offered. 2. As that member, press the switch button. The dialog closes and the page says the plan is no longer available. 3. The console's log shows `switch refused: product not published for members` at INFO, then `plan move failed` with `action=switch-preview` at ERROR. ### Why it matters An operator who alerts on ERROR lines, or reads them to find faults, is sent to look at members doing ordinary things, and real faults in the same function are harder to pick out.
cgalo5758 added the
kind
bug
area/billingarea/ops
labels 2026-10-30 22:51:33 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#303