Skip to content
Commit 9ab81894 authored by Stefy Lanza's avatar Stefy Lanza
Browse files

Fix payment schema migrations to match the code (SQLite + MySQL)



Several payment code paths referenced database schema that no migration ever
created, so they failed at runtime:

- distributed_locks: created the table used by PaymentScheduler._acquire_lock /
  _release_lock (it was referenced but never defined anywhere).
- email_notification_queue: the queue code uses context_json + retry_count, but
  the table was defined with recipient_email/subject/body. Redefined the table
  to match the code.
- crypto_consolidation_queue: WalletConsolidator writes user_id/from_address/
  to_address/amount, but the table had total_balance/address_count. Redefined to
  match the code.
- payment_methods.gateway: the base DatabaseManager schema creates
  payment_methods without a gateway column, so the migration's CREATE TABLE IF
  NOT EXISTS was a no-op and the column (read by the renewal processor) was
  missing. Added an idempotent ALTER.

Added cross-DB helpers (_table_exists/_column_exists work on both SQLite via
PRAGMA and MySQL via INFORMATION_SCHEMA). The two transient queue tables hold
only regenerable rows, so a legacy-shape table is dropped and recreated rather
than ALTERed column-by-column (avoids fragile cross-dialect constraint changes);
the gateway add is a plain additive ALTER guarded by _column_exists.

Co-Authored-By: default avatarClaude Opus 4.8 <noreply@anthropic.com>
parent 794dbe03
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment