🚀 Pruebas para transacciones fallidas: Lista de verificación para constructores de STONfi
La mayoría de los tutoriales de swaps se detienen en el camino feliz. Publicar solo eso y ya habrás probado tal vez el 60% de lo que de verdad ocurre en producción: la ejecución asincrónica basada en mensajes de TON produce formas de fallo que las intuiciones entrenadas para EVM no te preparan para ello.
🧭 Las fallas que realmente ocurren
Las devoluciones por deslizamiento funcionan como protección, no como un bug: prueba valores ajustados, holgados y de borde, no solo un único valor “razonable” por defecto. Los cross-swaps enrutados a través de un token intermediario no pueden reembolsar completamente si fallan a mitad de trayecto, porque las transacciones multi-contrato en TON no son atómicas: el usuario termina en posesión del token intermediario, no de su activo original de vuelta. Un problema real y documentado en GitHub muestra un swap que se transmite correctamente y luego falla en cadena con exit_code 11: prueba de que “la llamada de SDK no lanzó un error” nunca es lo mismo que “realmente se ejecutó con éxito”. Una parte significativa de fallos ni siquiera llega a un bloque: TonConnect rechaza direcciones malformadas, ventanas de validez expiradas y cancelaciones del usuario; la última de las cuales no debería “colarse” silenciosamente en tus logs de errores disfrazada de bug.
✅ Construye la matriz de pruebas alrededor de esto
Asertar el resultado del token intermediario para fallos parciales en cross-swaps, verificar códigos de salida en cadena después del envío en lugar de confiar solo en la llamada del SDK, separar el seguimiento de rechazos de la wallet de los fallos genuinos en cadena, y reconstruir cada transacción a partir de la cotización más reciente en vez de una en caché y obsoleta.
🏁 Prueba cómo falla realmente STONfi, no cómo fallan los swaps en general — y la brecha entre tu staging y tu primer ticket real de soporte se reduce rápidamente.
$XRP
La mayoría de los tutoriales de swaps se detienen en el camino feliz. Publicar solo eso y ya habrás probado tal vez el 60% de lo que de verdad ocurre en producción: la ejecución asincrónica basada en mensajes de TON produce formas de fallo que las intuiciones entrenadas para EVM no te preparan para ello.
🧭 Las fallas que realmente ocurren
Las devoluciones por deslizamiento funcionan como protección, no como un bug: prueba valores ajustados, holgados y de borde, no solo un único valor “razonable” por defecto. Los cross-swaps enrutados a través de un token intermediario no pueden reembolsar completamente si fallan a mitad de trayecto, porque las transacciones multi-contrato en TON no son atómicas: el usuario termina en posesión del token intermediario, no de su activo original de vuelta. Un problema real y documentado en GitHub muestra un swap que se transmite correctamente y luego falla en cadena con exit_code 11: prueba de que “la llamada de SDK no lanzó un error” nunca es lo mismo que “realmente se ejecutó con éxito”. Una parte significativa de fallos ni siquiera llega a un bloque: TonConnect rechaza direcciones malformadas, ventanas de validez expiradas y cancelaciones del usuario; la última de las cuales no debería “colarse” silenciosamente en tus logs de errores disfrazada de bug.
✅ Construye la matriz de pruebas alrededor de esto
Asertar el resultado del token intermediario para fallos parciales en cross-swaps, verificar códigos de salida en cadena después del envío en lugar de confiar solo en la llamada del SDK, separar el seguimiento de rechazos de la wallet de los fallos genuinos en cadena, y reconstruir cada transacción a partir de la cotización más reciente en vez de una en caché y obsoleta.
🏁 Prueba cómo falla realmente STONfi, no cómo fallan los swaps en general — y la brecha entre tu staging y tu primer ticket real de soporte se reduce rápidamente.
$XRP