Seed Catalog

Every seeder, what it creates, the run order, and the gotchas. This is the fixture layer the Test Catalog runs against. Reminder from the standing rules: you write seeders/migrations — the user applies them. Never run seed/migrate yourself.

The framework

The Seeder interface (database/seeder/seeder.go:14) has three methods — no priority, no declared dependencies:

type Seeder interface {
    Name() string
    Run(ctx, repository) error
    ShouldRun(ctx, repository) (bool, error)   // idempotency guard
}

Order = registration order. InitializeSeeder (runner.go:13-78) is the canonical list; RegisterSeeder just appends — there is no sort. RunAll (seeder.go:69) flushes the cache, then per seeder calls ShouldRun → Run, fail-fast (any error aborts the whole run). There is no wrapping transaction across seeders, and most seeders don't wrap their own work either (the eSIM orchestration seeders are the exceptions).

CLI (main.go:334 handleSeed)

Idempotency

Two ShouldRun patterns: row-count guard (SELECT COUNT(*), run only when 0/mismatch — countries, currencies, blacklists, order-item-responses, test-configs) and lookup-by-key (admin user, credentials, vendors/products by code, orchestration by product name). Writes are guarded inserts / upserts — no seeder truncates — so re-running is generally a safe no-op.

Registered seeders (run by seed all), in dependency order

41 registered in InitializeSeeder. Grouped by purpose; order is the actual run order.

Reference data (idempotent, prod-safe)

timezones (~431 from data/timezones.json) → countries (~245) → currencies (~156) → categories (10) → subcategories (16) → forex_values (~22 pairs). All load from data/*.json.

Config (clients, users, vendors)

admin_user (creates admin + the system_admin user that order/payout seeders use for transactions) → clients (29 from data/clients.json) → client_users (bcrypt password123) → tenant_connections → client_credentials → webhook_urls → users → wallets (USD/INR/AED per client) → products (57 from data/products.json; test products ids 13/14/15).

Vendor seeders (each writes vendors + vendor_attributes): vendors (Wupex WPX, iRewardify IRW, EpinForce, Grasshopper) → seagm_vendor → dtone_vendor (service_id 1) → dtone_esim_vendor (service_id 13 + webhook token) → runa_vendor → neo_vendor → octopus_vendor → octopus_topup_vendor (OCTO_TOPUP) → octopus_esim_vendor (OCTO_ESIM).

Then (order matters — after vendors and clients): client_vendor_blacklists, client_product_blacklists, vendor_products, vendor_wallets, client_product_details.

Fixtures (destructive on prod)

inventory (1000 voucher items) → orders (sample orders + items + responses inline) → payout providers merit_provider (MERIT) + ledig_provider (LEDIG) → beneficiaries → payouts → files.

Migration/backfill & test config

shopify_product_mapping_backfill (idempotent, UNIQUE-guarded — safe to leave registered) → test_configs (12 from data/test_configs.json, gated on client_id=10, runs last).

Unregistered seeders (test-invoked or disabled)

11 seeder files exist but are not in runner.go — invoked directly by orchestration tests, or disabled:

• Orchestration fixtures (test-invoked): dtone_topup_orchestration, dtone_esim_orchestration, seagm_topup_orchestration, octopus_topup_orchestration, octopus_esim_orchestration, and the voucher-side runa_vendor_products, neo_vendor_products, wupex_vendor_products, irewardify_vendor_products.
• Inline (done by the orders seeder): order_items, order_item_responses.
• Disabled stress seeders: bulk_orders (1000/wallet, runner.go:60), large_inventory (10,000 items, commented out runner.go:58).

Orchestration seeders — where seeders meet tests

Orchestration fixtures are no longer auto-seeded (runner.go:54); after a fresh DB, topup/eSIM/voucher products come only from vendor catalog sync, and each orchestration test calls its seeder in setup. Each wires: a pre-seeded parent vendor → one deterministic product+variant → credentials pointing at the mock server.

This coupling is fragile in one place: each voucher orchestration suite self-seeds its product because the shared vendor_product seeder randomly assigns variants to only the first 10 vendors, and Runa/others were added later — if seeder ordering changes, suites break.

Grasshopper D1 seed — a no-op

frontend/grasshopper/drizzle/seed.sql is verified to contain only SELECT 1+1 AS result;. Grasshopper's voucher_types catalog is repopulated by the Octopus → Grasshopper sync, not by a seed file (provisioning).

• db:seed → runs the no-op SQL.
• db:reset → local wipe + migrate + no-op seed.
• db:reset:remote → reset-remote.sh deletes+recreates the prod D1 with no confirmation — the most destructive item here — then migrates, no seed.
• db:reset:sandbox → reset-sandbox.sh, guarded (refuses if the DB name lacks "sandbox"), then instructs re-running the sync.

The mock rows the orchestration seeders point at live in mocky-balboa's own seed.sql/seed.ts (frontend/mocky-balboa/), the source of truth for those dtone_products/seagm_recharge_types ids.

Committed dev credentials (rotation review)

All appear to be dev/mock values but are in git:

These join the broader committed-secrets finding. Because no seeder has a prod guard, running a vendor/credential seeder against a shared env would overwrite live credentials with localhost mock values — the practical danger, beyond the fixtures simply inserting junk rows.

Key files

• Framework: database/seeder/{seeder,runner}.go; CLI main.go:96,265,334
• Data: database/seeder/data/*.json (timezones/countries/currencies/clients/products/test_configs)
• Orchestration: database/seeder/*_orchestration_seeder.go, *_vendor_product_seeder.go
• Grasshopper: frontend/grasshopper/drizzle/seed.sql, scripts/reset-{remote,sandbox}.sh; mock data frontend/mocky-balboa/