A plan change and the scheduled-change sweep wait up to four minutes on each Stripe call, past the end of the request #295
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: wiki-cafe/member-console#295
Reference in New Issue
Block a user
What happens
A member's plan change (a switch, a keep or a cancel) and the sweep that applies scheduled plan changes call Stripe without passing a context: for example
subscription.Getandsubscription.UpdateinupgradeNow(internal/fulfillment/plan_change.go:314,:324),subscriptionschedule.Newandsubscriptionschedule.UpdateindowngradeAtRenewal(:448,:488), andsubscription.Cancelandsubscription.Updatein the sweep (internal/fulfillment/sweep.go:174,:208). Each call therefore runs under the Stripe library's defaults, an 80-second timeout and two retries, about four minutes in all, whatever deadline the request or the sweep has. A downgrade makes up to four such calls in a row.The console ends a member's request after 32 seconds and cancels its context. The Stripe calls keep going, but the database reads and writes that follow them use the cancelled context and fail. A downgrade can create a subscription schedule at Stripe and then stop before it records the move, so the console's record of the plan is left to the webhook or to a later attempt.
The subscription reconcile's Stripe calls already carry their caller's context; these do not.
What should happen
Each Stripe call a plan change or the sweep makes ends at a deadline its caller chooses. For a write that may already have reached Stripe when its deadline passes, a stated rule says what the console does next, as it does for the reconcile's calls.
Where
internal/fulfillment/plan_change.go(upgradeNow,appliedUpgrade,downgradeAtRenewal,KeepCurrentPlan, the cancel path);internal/fulfillment/sweep.go.Why it matters
When Stripe is slow, a member's plan change can take effect at Stripe while the console records nothing, after the member was shown that the request failed.
A member's plan change (a switch to another tier, Keep plan, or Cancel plan) and the sweep that fires scheduled plan changes now give every Stripe call a deadline. A plan change's first call, its read of the subscription, ends with the member's request, so a request that ends before Stripe answers changes nothing. Every later call has a deadline of its own that outlasts the request's 32 seconds, 60 seconds for an upgrade's charge and 40 for the others (20 for the calls of the switch of a subscription paused for a grant, which resolves them before the member is answered), and after its last Stripe call the change records what it did (the console's record of a scheduled downgrade or cancellation) and reconciles the subscription within another 60 seconds. A member who closes the page, or whose request runs out of time, no longer leaves a change made at Stripe and unrecorded: the member reads the timeout answer, and the change finishes and is recorded. Every Stripe write now carries the idempotency key the Stripe library adds, so the library's own retries cannot repeat a write. A write that gets no answer before its deadline is reported as failed and records nothing, because Stripe's event for a write that did land brings the console in line. The one exception is a downgrade's update of its subscription schedule, which no event would record, so the console sends it with an idempotency key of its own and, when it gets no answer, sends it once more with the same key, and records the downgrade when that second send is answered. A change also checks that the request is still open before its first write, and its record supersedes only the scheduled changes that existed when it began, so a later request's cancellation or downgrade is not erased. The sweep gives each cancel or price change 20 seconds inside its one-minute run, and when less than 30 seconds is left it stops and leaves the remaining changes for its next attempt. The switch's price preview also ends with the request.
Commit:
4d7883c4