Call failed. Reject code: "undefined"

I got the following error when making a call to one of my canisters.

An error occurred: Error: Call failed: Canister: c2lt4-zmaaa-aaaaa-qaaiq-cai Method: execute_intent (update) "Request ID": "5530671debc024ff78d6de1a3279d8ee4c5a023d02664aebb5f85772532bfa14" "Reject code": "undefined" "Reject message": undefined

What’s the recommended way of debugging this issue? There’s no rejection code or rejection message.

Hi @vincentes, if you’re looking to debug a canister you control, maybe you could add some logs to your canister’s execute_intent function, to see more specifically what code path is leading to this reject.

Your canister ID seems not to exist from the p.o.v. of the ICP Registry, I’m wondering if you had this ID changed (which is fine). But then maybe it could help if you tell us which subnet your canister is installed on, and if it makes any calls to the Management canister in the execute_intent function?

Thanks. I ended up adding ic_cdk::println!("..") calls and also, I added myself as a controller to the canister and called dfx canister logs <canister-id>. This way, I was able to find out the issue. The problem was that the was a difference between the expected call arguments structure in Rust vs Candid.

Thanks for explaining the issue. Can you maybe add a few more details, ideally concrete code? This sounds like a situation that the CDK should support better and if we have an example it’s much easier to write something

I got the same error message when trying to make HTTP outcalls. I could also reproduce it in the motoko playground: play.motoko.org/?tag=1577772843

The error also persist if I change the code back to the original version, even after a reinstall.
Here is a short screen recording that shows the error: https://youtu.be/iiUt9mFvDg4

1 Like

Unfortunately, I didn’t commit the code, and already fixed the problem. I’ll make sure to keep track of the problem next time so that we can replicate it.

Thank you!

1 Like

That’s interesting. That definitely shouldn’t happen. A more user friendly error should be expected.

1 Like