mirror of
https://gitlab.com/pezkuwichain/pezkuwi-sdk.git
synced 2026-10-20 18:56:23 +00:00
Satoshi Qazi Muhammed
17de8a171d
listen_deposits/listen_withdrawals previously used ONLY a live finalized- block subscription with no persisted cursor - the last_polkadot_block/ last_pezkuwi_block fields existed in BridgeStats but were never read or written anywhere. A transient subscription gap (no logging, no crash, just a silently skipped block) could make a real deposit vanish from detection entirely. Confirmed live: a real user's 1 USDT deposit landed correctly at the multisig custody address (verified via direct chain balance query) but was never once logged as detected across 7+ hours of continuous uptime with zero errors - see res/validators-tiki.md 2026-07-15 for the full incident. Both listeners now: 1. On startup, compare the persisted checkpoint against current chain head and explicitly backfill (fetch block-by-hash via the legacy RPC's chain_get_block_hash, then process identically to the live path) any gap before starting the live subscription. 2. During live operation, detect if the subscription itself ever jumps ahead unexpectedly and backfill that gap too, paging Telegram when it happens. 3. Persist the checkpoint after every block processed, live or backfilled. process_deposit_block/process_withdrawal_block are the single shared per-block handlers - backfilled and live blocks run through identical logic, so there's no way for the two paths to silently diverge in behavior.