Files
at-container-registry/pkg/appview/db
Evan JarrettandClaude Opus 5 6510c16dd4 webhooks: enforce the entitlement at dispatch time
The webhook limit was only checked at creation, so losing entitlement (a
hold switch or a plan downgrade) left previously-created webhooks firing
paid behavior forever.

  - Dispatcher takes a WebhookLimiter, consulted on every dispatch. It
    caps the list to the current allowance, keeping the oldest N to match
    what the creation gate would have permitted, and masks paid trigger
    bits.
  - GetWebhooksForUser orders by created_at ASC, id ASC so that cap is
    deterministic. ListWebhooks gets the same tiebreak: it feeds the
    settings UI, and without it the list a user sees could disagree with
    the one the dispatcher truncates.
  - webhooks.FreeTriggerMask is shared by the creation gate and the
    dispatch backstop so the two cannot drift.

Capping is logged when it actually truncates. The webhooks stay visible in
settings, so from the user's side delivery would otherwise just stop with
no signal — and the same line is the only evidence if the limiter itself
degraded, since a billing lookup failure falls back to free-tier limits
and would quietly demote a paying user mid-dispatch.

Two cost fixes, both because this puts the entitlement lookup on a hot
path it was never on before:

findCustomerByDID now consults the customer cache instead of always
issuing a Stripe customer search. GetWebhookLimits reaches it via
GetSubscriptionInfo on every delivery, so uncached it meant a
rate-limited Search API call for every push and every scan record of
every user with a webhook configured.

DispatchForQuota checks whether the user has any quota webhook at all
before fetching the allowance. The original code filtered first precisely
so the common path (no quota webhooks) did no work; taking the allowance
up front would have spent the expensive lookup on every push. The cap
itself is still computed over the full list, since the count limit spans
all webhook types.

Note DeliverTest is deliberately not capped: it is an explicit,
user-initiated "send test" from the settings page, not automatic delivery.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-09 21:14:58 -05:00
..
2026-02-09 23:19:01 -06:00
2026-02-10 20:58:24 -06:00
2026-02-10 20:58:24 -06:00
2026-04-09 10:31:19 -05:00
2026-05-03 10:48:36 -05:00
2026-05-03 10:48:36 -05:00
2025-10-28 17:40:11 -05:00
2026-01-05 20:26:41 -06:00
2026-02-09 23:19:01 -06:00
2025-10-25 13:30:07 -05:00