A large tier removal or add is refused; the tier should retire and drain instead #237

New Issue

2026-10-18T06:16:21Z

cgalo5758 commented

2026-10-18 06:16:21 +00:00

The question

How can a tier be removed from a plan ladder, or a product added to one, when more organizations hold it than one transaction can move?

A tier removal deletes the tier, renumbers the ladder and moves every organization on it in one transaction. A tier add positions every organization that already holds the product. Both have to stay in one transaction today: an organization left positioned on a deleted tier has no rank, so its next plan change is recorded as initiate where an upgrade, downgrade or transfer belongs. Both also hold, for the whole act, the exclusive lock that every conferral waits on.

So #187 refuses a removal or add above a measured limit. Above that limit there is no way to remove a tier that many subscribers hold, or to add a product that many organizations hold. Moving the default plan first only clears the holders the default put there.

Depends on

#187: the record of the organizations a plan change still has to move, its background drain and its Retry.

Options known so far

Retire, then remove. The tier is marked retiring at once, so nothing new joins it. Each holder is moved off in its own short transaction through #187's record, and the tier is deleted when it is empty. A tier add mirrors this: the tier is added, and each holder is positioned on it in its own transaction. Two things this needs do not exist yet:
1. Stopping new conferrals onto a retiring tier. The conferral functions in the database decide where a conferral lands.
2. A rule for a pool that something else changes while it still waits on the record, for example a member who upgrades before their pool is moved. Today nothing settles a pool's pending obligations except the drain, so that upgrade would be recorded as initiate.
Keep the limit, and leave larger removals and adds impossible.

A retiring state may share its design with taking a ladder (#62) or a product (#97) out of service.

Decided when

A design states how each of the two needs is met, lists every failure path with what it commits, what the operator sees and how it is re-run, and gives the cost. If retire-then-remove is chosen, the limit in #187 goes with it.

### The question How can a tier be removed from a plan ladder, or a product added to one, when more organizations hold it than one transaction can move? A tier removal deletes the tier, renumbers the ladder and moves every organization on it in one transaction. A tier add positions every organization that already holds the product. Both have to stay in one transaction today: an organization left positioned on a deleted tier has no rank, so its next plan change is recorded as `initiate` where an upgrade, downgrade or transfer belongs. Both also hold, for the whole act, the exclusive lock that every conferral waits on. So #187 refuses a removal or add above a measured limit. Above that limit there is no way to remove a tier that many subscribers hold, or to add a product that many organizations hold. Moving the default plan first only clears the holders the default put there. ### Depends on #187: the record of the organizations a plan change still has to move, its background drain and its Retry. ### Options known so far - **Retire, then remove.** The tier is marked retiring at once, so nothing new joins it. Each holder is moved off in its own short transaction through #187's record, and the tier is deleted when it is empty. A tier add mirrors this: the tier is added, and each holder is positioned on it in its own transaction. Two things this needs do not exist yet: 1. Stopping new conferrals onto a retiring tier. The conferral functions in the database decide where a conferral lands. 2. A rule for a pool that something else changes while it still waits on the record, for example a member who upgrades before their pool is moved. Today nothing settles a pool's pending obligations except the drain, so that upgrade would be recorded as `initiate`. - **Keep the limit**, and leave larger removals and adds impossible. A retiring state may share its design with taking a ladder (#62) or a product (#97) out of service. ### Decided when A design states how each of the two needs is met, lists every failure path with what it commits, what the operator sees and how it is re-run, and gives the cost. If retire-then-remove is chosen, the limit in #187 goes with it.

cgalo5758 added the

kind

design

area/entitlements labels 2026-10-18 06:16:21 +00:00

cgalo5758 referenced this issue

2026-10-20 08:47:44 +00:00

Plan-wide changes to ladders and defaults run inside HTTP handlers, each with its own transaction shape #187

Sign in to join this conversation.