A downgrade Stripe holds is not shown when the console never recorded it #307
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: wiki-cafe/member-console#307
Reference in New Issue
Block a user
What happens
The console records a scheduled downgrade only in the switch that schedules it. The reconcile, which keeps the console's record true to Stripe, takes a recorded downgrade back when Stripe no longer holds it, but never records one Stripe holds.
A switch can make its last Stripe call, the update of the subscription schedule that carries the downgrade, and still leave no record. That happens when neither the call's answer nor the answer to its resend reaches the console, when Stripe answers it with a server error (which Stripe repeats to the resend), when Stripe is still executing it as the resend arrives, when the console's process stops between that call and the record, or when the console fails to write the record. Stripe then holds the downgrade and the console shows none: the plan's card names no downgrade, Keep plan finds nothing to take back, and the renewal moves the member down.
What should happen
The reconcile records a period-end downgrade from the subscription schedule the console attached, whose metadata names the price it was made from and whose last phase names the target, as it already takes one back when the schedule is gone. It also supersedes a period-end downgrade whose target the schedule's last phase does not carry, so two downgrades made close together leave one. Once it does, the resend of the downgrade's update becomes redundant and is removed, so that the console does not keep two mechanisms for one fact.
Where
internal/fulfillment/reconcile.go(convergeScheduledChanges),internal/fulfillment/plan_change.go(downgradeAtRenewal,sendScheduleUpdate)Why it matters
A member can be moved to a lower plan that the console never showed as scheduled and that Keep plan cannot take back.
Related: #177, #219, #275.
One more cause, on the first send rather than the resend. The Stripe library retries a write itself after a network fault, with the same idempotency key. If Stripe is still executing the first attempt when that retry arrives, Stripe answers 409, the library retries the 409 twice within about two seconds, and then returns it. The console reads a 409 as an answer from Stripe, so it treats the update as refused and does not send it again, although the first attempt can still land. Stripe then holds the downgrade and the console has no record of it, as above.