Files
pezkuwi-telegram-miniapp/supabase/functions/check-deposits
pezkuwichain 8d1e5f6af5 fix(deposits): stop runaway duplicate deposit rows, fix check-deposits reliability
Root cause chain found while investigating why TRC20/TON/Polkadot deposits
were never being credited after the self-hosted Supabase migration:

- DEPOSIT_TRON_HD_MNEMONIC, TRONGRID_API_KEY, DEPOSIT_TON_ADDRESS,
  DEPOSIT_POLKADOT_ADDRESS and the pg_cron job itself were never carried
  over during the 2026-04-09 migration, so check-deposits never ran.
- Once reconnected, the TRC20 loop was fully sequential (one address at a
  time) and hit the edge function's CPU/time budget with 50+ users -
  parallelized with a bounded concurrency of 8.
- The dedup check (select-by-tx_hash + .single()) breaks permanently once
  2+ rows ever share a tx_hash - .single() then errors on every future
  lookup, so the guard silently stops working and every cron tick
  reinserts. This is what produced 50k+ and 30k+ duplicate rows for two
  historical deposits back in April. Replaced with upsert +
  onConflict/ignoreDuplicates against a new unique constraint on tx_hash,
  so duplicates are impossible at the DB level regardless of app-level
  races.
- deposit_index 0 is the platform admin account and also used as the
  treasury sweep destination - excluded from the TRC20 scan so internal
  sweep transfers landing on it are never mistaken for a customer deposit.
2026-07-12 19:21:54 -07:00
..