#dusk $DUSK @Dusk
Tuve que leer esto dos veces porque un HTTP 202 Accepted normalmente hace que mi cerebro se relaje.
En Dusk, probablemente no debería.
Cuando /transactions/propagate devuelve 202 Accepted, el nodo ha aceptado la transacción para su enrutamiento.
Solo eso no prueba la transacción:
entró en el mempool real,
llegó a los peers,
ejecutó correctamente,
o se finalizó.
Al principio esto me pareció una distinción demasiado técnica.
Luego encontré el caso límite más extraño.
Una transacción válida con un nonce futuro puede esperar en una precola hasta que se resuelva el hueco del nonce que falta.
Así que puedes recibir una respuesta de API perfectamente limpia mientras la transacción aún no está en la etapa que probablemente te importa.
Esa parte me molestó.
Muchísima infraestructura se construye alrededor de un atajo muy humano:
La API dijo que sí → trabajo hecho.
La guía de integración de intercambios de Dusk asume lo contrario.
Una retirada no debería tratarse como completada solo porque el endpoint de propagación devolvió 202 Accepted. La ejecución y la finalización todavía deben verificarse.
Y si la capa de transporte expira, la ruta de recuperación más segura es reenviar la misma transacción firmada, no crear otra a ciegas.
Ahí es donde esto deja de ser una curiosidad de código de estado HTTP.
Si un exchange o una wallet confunden la aceptación del transporte con la finalización del libro mayor, un pequeño atajo de integración puede convertirse en un problema de contabilidad.
Quizá estoy sobrepensando una respuesta aburrida de API por la noche.
Pero creo que la distinción útil es simple:
El éxito del transporte no es éxito del libro mayor.
La API puede decir que sí antes de que lo haga la cadena.
Tuve que leer esto dos veces porque un HTTP 202 Accepted normalmente hace que mi cerebro se relaje.
En Dusk, probablemente no debería.
Cuando /transactions/propagate devuelve 202 Accepted, el nodo ha aceptado la transacción para su enrutamiento.
Solo eso no prueba la transacción:
entró en el mempool real,
llegó a los peers,
ejecutó correctamente,
o se finalizó.
Al principio esto me pareció una distinción demasiado técnica.
Luego encontré el caso límite más extraño.
Una transacción válida con un nonce futuro puede esperar en una precola hasta que se resuelva el hueco del nonce que falta.
Así que puedes recibir una respuesta de API perfectamente limpia mientras la transacción aún no está en la etapa que probablemente te importa.
Esa parte me molestó.
Muchísima infraestructura se construye alrededor de un atajo muy humano:
La API dijo que sí → trabajo hecho.
La guía de integración de intercambios de Dusk asume lo contrario.
Una retirada no debería tratarse como completada solo porque el endpoint de propagación devolvió 202 Accepted. La ejecución y la finalización todavía deben verificarse.
Y si la capa de transporte expira, la ruta de recuperación más segura es reenviar la misma transacción firmada, no crear otra a ciegas.
Ahí es donde esto deja de ser una curiosidad de código de estado HTTP.
Si un exchange o una wallet confunden la aceptación del transporte con la finalización del libro mayor, un pequeño atajo de integración puede convertirse en un problema de contabilidad.
Quizá estoy sobrepensando una respuesta aburrida de API por la noche.
Pero creo que la distinción útil es simple:
El éxito del transporte no es éxito del libro mayor.
La API puede decir que sí antes de que lo haga la cadena.
