Skip to content

add storage addon purchases - #3737

Draft
emma-sg wants to merge 19 commits into
yearly-plansfrom
storage-addons
Draft

emma-sg wants to merge 19 commits into
yearly-plansfrom
storage-addons

Conversation

@emma-sg

@emma-sg emma-sg commented Oct 13, 2026

Copy link
Copy Markdown
Member

No description provided.

@emma-sg
emma-sg added this pull request to stack #3738 October 13, 2026 23:41
@emma-sg emma-sg added this to the 1.27 Release milestone Oct 27, 2026
an org's available storage is its plan quota plus any add-on it has
purchased, so the add-on is included wherever the plan quota is compared
to usage.
the external subscription app owns a subscription's add-on size, billing
cycle, and any change scheduled for the next renewal. the billing
interval, the pending add-on size, and the pending plan are stored on the
subscription.

values the app has nothing for are left out of the JSON it sends, so a
missing value clears what is stored rather than leaving it as it was.
the add-on is owned by the external subscription app, so changes are
forwarded to it. a reduction below current usage is rejected here first,
which means the org has to free space before a change can land.

when the size changes it is copied into the org's extra storage quota.
the app sends the size on every update, so an unchanged value writes
nothing.
the external subscription app checks a reduction made in the Stripe
portal against the org's real quota, which can differ from the plan's
default, and against actual usage, so both are exposed behind the shared
secret the app already uses.
when a reduction made in the Stripe portal would leave the org over its
storage limit, the subscription app cancels it, and nothing in Browsertrix
warned the person who made the change, so the org admins get an email with
what the org is using, what the plan allows, and the smallest add-on that
would fit.

the app retries failed events, so the last cancelled size is remembered
and an email is sent only once for it.
the org owner can add, change, or cancel the add-on from billing settings.
an increase is charged right away, while a reduction or cancellation takes
effect at the next renewal, and a pending change is shown next to the
current size so it can be kept or undone.

clean multiples of 1,000 GB render as TB, so the quota line's add-on note
does not read "1,000 GB" beside "1 TB".
a pod that is hard-killed mid-job can re-run after the org document has
been deleted, and the missing org would fail the job. a delete-org job's
earlier attempt already did the work, so it finishes with success and its
k8s resources get cleaned up. every other job type needs the org, so a
missing one stays fatal.
claims carry a timestamp, so a pod killed mid-migration leaves a lease
that expires and can be re-claimed rather than blocking the final wait
loop forever. a claim older than the lease is treated as orphaned and the
crawl is re-processed, which is idempotent. the wait loop only blocks on
un-migrated crawls whose claim is still fresh.
`monthly_remaining_time` is clamped to zero. a quota that dropped below
the month's recorded usage could otherwise go negative, which subtracted
from `monthlyExecSeconds` and charged the whole overage difference to the
plan/gifted/extra pools.
migrated from `appState.settings`

This branch has not been deployed

No deployments
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