Files
at-container-registry/pkg/appview/db/migrations
Evan JarrettandClaude Opus 5 12c55ed560 billing: make Stripe webhook delivery idempotent and retryable
Webhook delivery was neither idempotent nor order-safe, and every failure
returned 400, which Stripe does not retry. A transient DB or hold error
therefore dropped a subscription change silently and permanently.

  - New stripe_processed_events table: event_id as primary key dedups
    redelivery, and event_created per customer drops stale out-of-order
    deliveries.
  - HandleWebhook distinguishes ErrWebhookSignature (400, no retry) from
    ErrWebhookProcessing (500, Stripe redelivers). The event handlers
    return errors instead of swallowing them. ErrBillingDisabled maps to
    400: the route is mounted but billing is off, so redelivery can never
    succeed and Stripe should stop rather than retry to exhaustion.
  - Refuse to boot when billing is enabled with an empty
    STRIPE_WEBHOOK_SECRET. Stripe HMACs with the empty key, so an
    attacker can reproduce the signature and the endpoint is forgeable.
  - UpdateCrewTierOnAllHolds retries each hold (3 attempts, linear
    backoff, 5s per request) and returns a joined error so the webhook
    can fail and let Stripe redeliver.

The fan-out contacts holds concurrently rather than in sequence. Serially,
one unreachable hold burns the caller's entire 10s budget on its own
retries (3 x 5s plus backoff) and the holds after it are never contacted;
because Stripe redelivers in the same order, a persistently-down first
hold means the rest are never updated at all.

On the hold, the signature-validated sub claim is now the source of truth
for updateCrewTier: a mismatched body userDid is rejected with 403 rather
than retargeting the grant to another DID. "Not crew on this hold" is a
200 no-op, since the appview fans updates out to every managed hold and a
subscriber is not crew everywhere.

That no-op has to be told apart from a storage failure. GetCrewMember
collapsed both into one generic error, so a CAR-store failure read as
"not a member", answered 200, and let the appview record the event as
processed — losing the tier grant permanently, which is exactly the
failure mode this commit exists to prevent. Missing records now carry an
ErrCrewMemberNotFound sentinel, and anything else returns 500 so Stripe
redelivers.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-09 21:14:58 -05:00
..
2025-10-28 17:40:11 -05:00

Database Migrations

This directory contains database migrations for the ATCR AppView database.

Schema vs Migrations

schema.sql (in parent directory) contains the complete base schema for fresh database installations. It includes all tables, indexes, and constraints.

Migrations (this directory) handle changes to existing databases. They are only for:

  • ALTER TABLE statements (add/modify/drop columns)
  • UPDATE statements (data transformations)
  • DELETE statements (data cleanup)
  • Creating/modifying indexes on existing tables

NEW TABLES go in schema.sql, NOT in migrations.

Migration Format

Each migration is a YAML file with the following structure:

description: Optional human-readable description of what this migration does
query: |
  SQL commands to apply the migration

Version and name are parsed from the filename, so you don't need to specify them in the YAML.

Naming Convention

Migration files must be named: {version:04d}_{migration_name}.yaml

The filename determines:

  • Version: Numeric prefix (e.g., 0001 → version 1)
  • Name: Everything after first underscore (e.g., add_repository_labels → "add repository labels")

Examples:

  • 0001_remove_star_count_from_repository_stats.yaml → version 1, name "remove star count from repository stats"
  • 0002_add_repository_labels.yaml → version 2, name "add repository labels"
  • 0003_create_webhooks_table.yaml → version 3, name "create webhooks table"

Creating a New Migration

  1. Choose the next version number - Look at existing migrations and increment by 1
  2. Create a new YAML file with format 000N_descriptive_name.yaml
  3. Add description (optional) - Explain what the migration does
  4. Write your SQL in query - Use the | block scalar for clean multi-line SQL
  5. Use IF EXISTS / IF NOT EXISTS where possible for idempotency

Examples

Adding a column to existing table:

Filename: 0007_add_readme_url_to_manifests.yaml

description: Add readme_url column to manifests table for storing io.atcr.readme annotation
query: |
  ALTER TABLE manifests ADD COLUMN readme_url TEXT;

IMPORTANT: After creating this migration, also add the column to schema.sql so fresh installations include it!

Data transformation migration:

Filename: 0005_normalize_hold_endpoint_to_did.yaml

description: Normalize hold_endpoint column to store DIDs instead of URLs
query: |
  -- Convert HTTPS URLs to did:web: format
  UPDATE manifests
  SET hold_endpoint = 'did:web:' || substr(hold_endpoint, 9)
  WHERE hold_endpoint LIKE 'https://%';

  -- Convert HTTP URLs to did:web: format
  UPDATE manifests
  SET hold_endpoint = 'did:web:' || substr(hold_endpoint, 8)
  WHERE hold_endpoint LIKE 'http://%';

Adding an index to existing table:

Filename: 0008_add_repository_description_index.yaml

description: Add index on manifests description field for faster searches
query: |
  CREATE INDEX IF NOT EXISTS idx_manifests_description ON manifests(description);

How Migrations Run

  1. Migrations are loaded from this directory on startup
  2. Sorted by version number (ascending)
  3. Each migration is checked against the schema_migrations table
  4. Only unapplied migrations are executed
  5. After successful execution, the version is recorded in schema_migrations

Important Notes

  • Never modify existing migrations - Once applied, they're immutable
  • Test migrations before committing - Ensure they work on existing databases
  • Version numbers must be unique - The migration system will fail if duplicates exist
  • Migrations run automatically on InitDB() - Schema first, then migrations
  • CRITICAL: Update schema.sql for structural changes - When you ALTER a table or add columns, update both the migration AND schema.sql so fresh installations have the same structure
  • New tables go in schema.sql only - Don't create migration files for new tables