Does not detect failed Sudo calls #295
-
The receipt.is_success and receipt.error_message are all good even though the extrinsic failed, the error is within the Sudo module and the process_events() does not parse it. Is it meant to work this way? Output of receipt.triggered_events
|
Beta Was this translation helpful? Give feedback.
Replies: 4 comments
-
I don't have more context, but from the events you provided, it seems like the extrinsic succeeded and not failed: Where did you see that your extrinsic failed? Did you perhaps saw events that are triggered by another extrinsic in the same block? |
Beta Was this translation helpful? Give feedback.
-
Sudo extrinsic is shown as Success but the actual execution failed, you can see this if you scroll along the logs The process_events() misses it since the extrinsic is marked as Success, I am getting around by looking for it specifically like this
Again not sure if its meant to work like this, but adding this to the process_events() would be useful. |
Beta Was this translation helpful? Give feedback.
-
Ok gotcha, I missed that attribute at first glance. I can understand this seems not intuitive, but this is not something that should be altered in the library, because it is just translating the behaviour of this call in the Substrate runtime. Apparently in the This is a design decision of that Substrate runtime pallet, so I believe best practice is to translate this as such to the applications interfacing with it in the most generic and unmodified way. Added exceptions in a library will just add confusing I'm afraid, because then behaviour wil differ from other libraries like PolkadotJS. PolkadotJS is showing the same behaviour: |
Beta Was this translation helpful? Give feedback.
-
Makes sense. Thanks |
Beta Was this translation helpful? Give feedback.
Ok gotcha, I missed that attribute at first glance.
I can understand this seems not intuitive, but this is not something that should be altered in the library, because it is just translating the behaviour of this call in the Substrate runtime.
Apparently in the
Sudo
pallet aBadOrigin
is interpreted as successful (executed with a valid Sudo account, but not allowed for given call). And for example aRequireSudo
is a failure, because it is executed with an invalid Sudo account.This is a design decision of that Substrate runtime pallet, so I believe best practice is to translate this as such to the applications interfacing with it in the most generic and unmodified way. Added exceptions in…