An org type's default ladder can start on a product that confers nothing, and then restoring the default fails #153

New Issue

2026-09-28T08:23:54Z

cgalo5758 commented

2026-09-28 08:23:54 +00:00

The Default Plan control on the org types page refuses a ladder with no rank-0 tier: the preview renders an error instead. It accepts a ladder whose rank-0 product has no entitlement set. Once such a ladder is an org type's default, restoring the default fails for every organization of that type.

What happens

Restoring the default confers the default ladder's rank-0 product, and core.confer refuses a product with no entitlement set. An operator's revoke of a grant in such an organization fails with:

failed to revoke grant … restore default for pool …: reapply-defaults: confer default grant: confer grant: ERROR: confer: product … has no entitlement set and confers nothing

The operator's confirm dialog then ends without a success notice. The same restore (ReapplyDefaultsIfVacant) also runs after a subscription ends, after a grant expires and after an org-type migration, so those paths meet the same refusal. Only the revoke path was observed failing; the others were not exercised.

How to reproduce

The browser walkthroughs share the app database across runs:

The plan-ladders walkthrough creates a ladder whose two tiers have no entitlement set.
The org-types walkthrough then makes it the personal org type's default.
On the next run, the grant-revoke walkthrough's revoke fails as above.

On a freshly reset database, grant-revoke runs before the other two, so the suite passes.

Where it could be stopped

In the default-change preview, alongside the existing refusal of a ladder with no rank-0 tier.
Or where a ladder's tiers are chosen, since a rung that confers nothing can never be delivered by any source.

Related: #98 (a product never shows what it delivers).

The Default Plan control on the org types page refuses a ladder with no rank-0 tier: the preview renders an error instead. It accepts a ladder whose rank-0 product has no entitlement set. Once such a ladder is an org type's default, restoring the default fails for every organization of that type. ## What happens Restoring the default confers the default ladder's rank-0 product, and `core.confer` refuses a product with no entitlement set. An operator's revoke of a grant in such an organization fails with: ``` failed to revoke grant … restore default for pool …: reapply-defaults: confer default grant: confer grant: ERROR: confer: product … has no entitlement set and confers nothing ``` The operator's confirm dialog then ends without a success notice. The same restore (`ReapplyDefaultsIfVacant`) also runs after a subscription ends, after a grant expires and after an org-type migration, so those paths meet the same refusal. Only the revoke path was observed failing; the others were not exercised. ## How to reproduce The browser walkthroughs share the app database across runs: 1. The plan-ladders walkthrough creates a ladder whose two tiers have no entitlement set. 2. The org-types walkthrough then makes it the personal org type's default. 3. On the next run, the grant-revoke walkthrough's revoke fails as above. On a freshly reset database, grant-revoke runs before the other two, so the suite passes. ## Where it could be stopped - In the default-change preview, alongside the existing refusal of a ladder with no rank-0 tier. - Or where a ladder's tiers are chosen, since a rung that confers nothing can never be delivered by any source. Related: #98 (a product never shows what it delivers).

cgalo5758 added the

kind

bug

area/entitlements area/catalog area/operator-ui labels 2026-09-28 08:23:54 +00:00

cgalo5758 referenced this issue

2026-09-28 08:37:29 +00:00

The default comes back as a new grant each time, while a marked grant comes back as itself: two mechanisms for one idea #154

cgalo5758 referenced this issue from a commit

2026-10-10 21:47:21 +00:00

Characterize the plan-wide acts: answers, log lines, writes and locks, and the rows they leave

cgalo5758 referenced this issue

2026-10-10 23:59:46 +00:00