Skip to content

scalable: reused state inherits every behavior attached to it#16

Merged
pallaoro merged 1 commit into
mainfrom
scalable-reused-state-inherits-behavior
Jul 9, 2026
Merged

scalable: reused state inherits every behavior attached to it#16
pallaoro merged 1 commit into
mainfrom
scalable-reused-state-inherits-behavior

Conversation

@pallaoro

@pallaoro pallaoro commented Jul 9, 2026

Copy link
Copy Markdown
Member

What

Adds one bullet to `commands/scalable.md`, right after "don't optimize away the domain object."

That existing bullet warns against reuse that deletes the domain object. This adds its mirror: reuse that silently inherits a hidden behavior.

Why

Repurposing an existing status / flag / enum / column to mean something new (e.g. trialing to mean "currency-migration bridge") doesn't just carry the one property you want — it fires everything already wired to that value: webhooks, crons, entitlement gates, billing/credit grants, UI branches, cleanup jobs.

Real case that motivated this: a subscription currency-migration reused Stripe's trialing status purely to defer a charge. /scalable correctly flagged two inherited behaviors (orphan-cancel, upgrade block) — but only reactively, after being prompted. A third — trialing sub creation emitting a $0 invoice → invoice.paid → a full plan-credit grant — went unnoticed until it had minted a duplicate month of credits for every migrated customer.

The fix is mechanical, not conceptual: grep every consumer of the reused value up front and enumerate what each does, rather than validating the one behavior you wanted and discovering the rest one bug at a time. Plus a verification note: diff the whole system's response (side-effect tables, ledgers), not just the fields you predicted.

The existing 'don't optimize away the domain object' bullet warns against
reuse that deletes the domain object. Add its mirror: reuse that silently
inherits a hidden behavior. Repurposing an existing status/flag/enum/column
(e.g. trialing to mean 'migration bridge') fires everything that already
reads that value — webhooks, crons, entitlement gates, billing/credit
grants, UI branches, cleanup jobs — not just the one property you wanted.
Enumerate consumers up front (grep every reader) instead of discovering
them reactively one bug at a time, and verify by diffing the whole
system's response, not just the fields you predicted would change.
@pallaoro
pallaoro merged commit 74dae59 into main Jul 9, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant