Un contrato de cierre puede mantener el saldo correcto de DUSK mientras mi monitor de tesorería de repente no lee nada después de una “actualización” de una API.
La trampa no está en el contrato. Está en la forma de la respuesta.
La ruta /on/contract anterior: <id>/status devolvía un objeto con el balance dentro. La ruta de reemplazo consulta contract_balance a través del contrato génesis de Transfer de Dusk, y la respuesta es el saldo escalar en sí.
Así que, si migro el endpoint pero dejo el analizador (parser) intacto, response.balance desaparece. Un fallback como undefined → 0 puede hacer que un contrato con fondos parezca vacío aunque el saldo en cadena nunca haya cambiado.
Ese es el tipo de bug de mantenimiento que esperaría que sobreviviera a comprobaciones básicas de salud. Rusk responde. La solicitud tiene éxito. El contrato existe. Solo la interpretación es incorrecta.
Yo fijaría un balance conocido de contrato en la prueba de migración y compararía los valores antiguos versus los nuevos antes de cambiar las lecturas de producción. No solo HTTP 200. No solo JSON válido. El mismo entero LUX debe sobrevivir el límite del parser.
Si una tesorería de Dusk puede mantener fondos correctamente mientras mi software informa cero, la migración de la API ha cambiado el estado financiero que mi operador cree que existe.
#dusk $DUSK @Dusk
La trampa no está en el contrato. Está en la forma de la respuesta.
La ruta /on/contract anterior: <id>/status devolvía un objeto con el balance dentro. La ruta de reemplazo consulta contract_balance a través del contrato génesis de Transfer de Dusk, y la respuesta es el saldo escalar en sí.
Así que, si migro el endpoint pero dejo el analizador (parser) intacto, response.balance desaparece. Un fallback como undefined → 0 puede hacer que un contrato con fondos parezca vacío aunque el saldo en cadena nunca haya cambiado.
Ese es el tipo de bug de mantenimiento que esperaría que sobreviviera a comprobaciones básicas de salud. Rusk responde. La solicitud tiene éxito. El contrato existe. Solo la interpretación es incorrecta.
Yo fijaría un balance conocido de contrato en la prueba de migración y compararía los valores antiguos versus los nuevos antes de cambiar las lecturas de producción. No solo HTTP 200. No solo JSON válido. El mismo entero LUX debe sobrevivir el límite del parser.
Si una tesorería de Dusk puede mantener fondos correctamente mientras mi software informa cero, la migración de la API ha cambiado el estado financiero que mi operador cree que existe.
#dusk $DUSK @Dusk