Plan cards make a limit's singular by cutting a trailing "s", and drop their limit lines without an error when the rules cannot be read #201

New Issue

2026-10-09T16:02:10Z

cgalo5758 commented

2026-10-09 16:02:10 +00:00

What happens

Each tier card on the Products page lists the tier's limits as " ". entitlementFeatures builds these lines from the rules of the product's entitlement set and each resource key's display name. Two things go wrong there.

The singular is guessed. When a limit is 1 and the display name ends in "s", the last letter is cut, so "Wiki Sites" reads "1 Wiki Site". That works only for names whose plural is the singular plus "s". A display name such as "Mailboxes" reads "1 Mailboxe", "Entries" reads "1 Entrie", and a singular that ends in "s", such as "Address", reads "1 Addres". When the label read fails, labelFor falls back to the raw key, and the card reads "1 fedwiki_site". The registry already stores a singular noun for each key in core.resource_keys.unit ("site" for fedwiki_sites). ListResourceKeyLabels selects that column, but resolveResourceLabels drops it. Every other count the console prints goes through pluralize, which is given both forms.
A failed rules read draws a shorter card. buildPlanFeatures reads the rules with GetActiveRulesBySetID. When that read fails, it carries on with no limit lines and writes nothing to the log. The card shows only the strings from the product's metadata.features, or no features at all, and looks complete. Every other failed read in buildPlansData logs the error and the section answers "Failed to load plans" (plansLoadFailed).

What should happen

A limit of 1 reads in a singular form the console was given, never one made by cutting letters off the display name. The catalog spec's example in openspec/specs/member-product-discovery/spec.md ("1 wiki sites") changes with the fix.

A failed rules read is logged with its error and reported like the section's other failed reads. A member never sees a card that lists fewer limits than the plan grants without being told why.

Where

internal/server/member_plans.go (buildPlanFeatures, entitlementFeatures); internal/server/member_entitlements.go (resolveResourceLabels). TestPlanFeatures in internal/server/member_plan_features_test.go pins both behaviours as they are today.

Why it matters

A member choosing a plan reads its limits from these lines. A misspelt noun makes the catalog look broken. A card missing its limits undersells the plan, and nothing in the log shows why.

## What happens Each tier card on the Products page lists the tier's limits as "<value> <name>". `entitlementFeatures` builds these lines from the rules of the product's entitlement set and each resource key's display name. Two things go wrong there. - **The singular is guessed.** When a limit is 1 and the display name ends in "s", the last letter is cut, so "Wiki Sites" reads "1 Wiki Site". That works only for names whose plural is the singular plus "s". A display name such as "Mailboxes" reads "1 Mailboxe", "Entries" reads "1 Entrie", and a singular that ends in "s", such as "Address", reads "1 Addres". When the label read fails, `labelFor` falls back to the raw key, and the card reads "1 fedwiki_site". The registry already stores a singular noun for each key in `core.resource_keys.unit` ("site" for `fedwiki_sites`). `ListResourceKeyLabels` selects that column, but `resolveResourceLabels` drops it. Every other count the console prints goes through `pluralize`, which is given both forms. - **A failed rules read draws a shorter card.** `buildPlanFeatures` reads the rules with `GetActiveRulesBySetID`. When that read fails, it carries on with no limit lines and writes nothing to the log. The card shows only the strings from the product's `metadata.features`, or no features at all, and looks complete. Every other failed read in `buildPlansData` logs the error and the section answers "Failed to load plans" (`plansLoadFailed`). ## What should happen A limit of 1 reads in a singular form the console was given, never one made by cutting letters off the display name. The catalog spec's example in `openspec/specs/member-product-discovery/spec.md` ("1 wiki sites") changes with the fix. A failed rules read is logged with its error and reported like the section's other failed reads. A member never sees a card that lists fewer limits than the plan grants without being told why. ## Where `internal/server/member_plans.go` (`buildPlanFeatures`, `entitlementFeatures`); `internal/server/member_entitlements.go` (`resolveResourceLabels`). `TestPlanFeatures` in `internal/server/member_plan_features_test.go` pins both behaviours as they are today. ## Why it matters A member choosing a plan reads its limits from these lines. A misspelt noun makes the catalog look broken. A card missing its limits undersells the plan, and nothing in the log shows why.

cgalo5758 added the

kind

bug

area/catalog area/member-ui labels 2026-10-09 16:02:10 +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#201