🚀 Тестирование неудачных транзакций: чек-лист строителя для STONfi
Большинство туториалов по свапам заканчиваются счастливым сценарием. Если выпустить только его, вы протестируете, возможно, лишь 60% того, с чем столкнетесь в продакшене — асинхронное, основанное на сообщениях исполнение TON формирует формы отказов, к которым EVM-ориентированные инстинкты не готовят.
🧭 Отказы, которые действительно происходят
Возвраты из‑за слиппеджа — это защита, которая работает так, как задумано, а не баг; тестируйте узкие, свободные и граничные значения, а не только одно «разумное» значение по умолчанию. Кросс‑свапы, проложенные через промежуточный токен, не могут полностью откатить при сбое в середине пути: мульти-контрактные транзакции в TON не являются атомарными — пользователь в итоге держит промежуточный токен, а не возвращает исходный актив. Одна реальная задокументированная проблема на GitHub показывает, что свап отправляется в сеть чисто, а затем падает on-chain с exit_code 11 — доказательство того, что «вызов SDK не выбросил исключение» никогда не равно «фактически успешно завершилось». Значимая доля отказов вообще не доходит до блока: TonConnect отклоняет некорректные адреса, истекшие окна валидности и отмены со стороны пользователя — последняя категория не должна тихо оседать в ваших error‑логах, маскируясь под баг.
✅ Постройте матрицу тестов на основе этого
Проверяйте исход промежуточного токена при частичных сбоях кросс‑свапов, подтверждайте on-chain exit-коды после отправки, а не полагайтесь только на вызов SDK, отделяйте трекинг отклонений кошельком от реальных on-chain отказов и пересобирайте каждую транзакцию по последней котировке, а не по устаревшей, закэшированной.
🏁 Тестируйте, как STONfi реально ломается, а не то, как свапы ломаются вообще — и разрыв между стендом и вашим первым реальным тикетом в поддержку быстро сократится.
$XRP
Большинство туториалов по свапам заканчиваются счастливым сценарием. Если выпустить только его, вы протестируете, возможно, лишь 60% того, с чем столкнетесь в продакшене — асинхронное, основанное на сообщениях исполнение TON формирует формы отказов, к которым EVM-ориентированные инстинкты не готовят.
🧭 Отказы, которые действительно происходят
Возвраты из‑за слиппеджа — это защита, которая работает так, как задумано, а не баг; тестируйте узкие, свободные и граничные значения, а не только одно «разумное» значение по умолчанию. Кросс‑свапы, проложенные через промежуточный токен, не могут полностью откатить при сбое в середине пути: мульти-контрактные транзакции в TON не являются атомарными — пользователь в итоге держит промежуточный токен, а не возвращает исходный актив. Одна реальная задокументированная проблема на GitHub показывает, что свап отправляется в сеть чисто, а затем падает on-chain с exit_code 11 — доказательство того, что «вызов SDK не выбросил исключение» никогда не равно «фактически успешно завершилось». Значимая доля отказов вообще не доходит до блока: TonConnect отклоняет некорректные адреса, истекшие окна валидности и отмены со стороны пользователя — последняя категория не должна тихо оседать в ваших error‑логах, маскируясь под баг.
✅ Постройте матрицу тестов на основе этого
Проверяйте исход промежуточного токена при частичных сбоях кросс‑свапов, подтверждайте on-chain exit-коды после отправки, а не полагайтесь только на вызов SDK, отделяйте трекинг отклонений кошельком от реальных on-chain отказов и пересобирайте каждую транзакцию по последней котировке, а не по устаревшей, закэшированной.
🏁 Тестируйте, как STONfi реально ломается, а не то, как свапы ломаются вообще — и разрыв между стендом и вашим первым реальным тикетом в поддержку быстро сократится.
$XRP