Le contrat peut être correct et mon appel à DuskVM peut quand même mourir sur deux caractères.
Les entrées de DuskVM ne sont pas envoyées sous forme de JSON lisible. Il s’agit d’octets encodés au format rkyv, et Forge utilise le pilote de données off-chain du contrat pour transformer quelque chose d’humain comme 42 en les octets que le contrat attend réellement.
La partie délicate, c’est la transmission. Forge me donne cette valeur encodée en hexadécimal avec un préfixe 0x. Un SDK peut vouloir que ce préfixe soit conservé. L’option --fn-args de Rusk Wallet m’oblige à la supprimer.
Je peux donc tester la logique du contrat, vérifier le WASM, encoder l’argument correctement, puis faire échouer l’appel en direct en passant exactement les mêmes octets dans la mauvaise forme de transport.
C’est le bug d’intégration que je protégerais le plus. Pas parce que c’est spectaculaire, mais parce que tout en amont a l’air sain. La fonction existe. Le schéma est correct. La valeur est correcte. L’échec se situe à la frontière entre le pilote de données et l’émetteur.
Si je construisais une application DuskVM, je normaliserais les arguments d’appel une fois et je testerais cette frontière pour chaque chemin de soumission que je prends en charge.
Deux caractères ne devraient jamais être la raison pour laquelle une action de contrat valide se transforme en transaction utilisateur échouée.
#dusk $DUSK @Dusk
Les entrées de DuskVM ne sont pas envoyées sous forme de JSON lisible. Il s’agit d’octets encodés au format rkyv, et Forge utilise le pilote de données off-chain du contrat pour transformer quelque chose d’humain comme 42 en les octets que le contrat attend réellement.
La partie délicate, c’est la transmission. Forge me donne cette valeur encodée en hexadécimal avec un préfixe 0x. Un SDK peut vouloir que ce préfixe soit conservé. L’option --fn-args de Rusk Wallet m’oblige à la supprimer.
Je peux donc tester la logique du contrat, vérifier le WASM, encoder l’argument correctement, puis faire échouer l’appel en direct en passant exactement les mêmes octets dans la mauvaise forme de transport.
C’est le bug d’intégration que je protégerais le plus. Pas parce que c’est spectaculaire, mais parce que tout en amont a l’air sain. La fonction existe. Le schéma est correct. La valeur est correcte. L’échec se situe à la frontière entre le pilote de données et l’émetteur.
Si je construisais une application DuskVM, je normaliserais les arguments d’appel une fois et je testerais cette frontière pour chaque chemin de soumission que je prends en charge.
Deux caractères ne devraient jamais être la raison pour laquelle une action de contrat valide se transforme en transaction utilisateur échouée.
#dusk $DUSK @Dusk