mirror of
https://github.com/pezkuwichain/pezkuwi-telegram-miniapp.git
synced 2026-07-22 12:05:45 +00:00
pezkuwichain
8d1e5f6af5
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.
9 lines
554 B
SQL
9 lines
554 B
SQL
-- Prevent duplicate deposit records for the same on-chain transaction.
|
|
-- Without this constraint, a check-then-insert race in check-deposits
|
|
-- (concurrent invocations, or any transient duplicate) permanently breaks
|
|
-- the .single() dedup lookup once 2+ rows share a tx_hash, causing every
|
|
-- subsequent cron run to re-insert indefinitely. This happened in
|
|
-- production: two tx_hashes accumulated 50k+ and 30k+ duplicate rows
|
|
-- respectively before being cleaned up.
|
|
ALTER TABLE tg_deposits ADD CONSTRAINT tg_deposits_tx_hash_unique UNIQUE (tx_hash);
|