Tidy up inter-canister calls #3881
Open
+4
−4
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Strengthen the specification of `ic0.call_perform` as discussed in the interface spec meeting. Also unify the naming of reject codes (previously was also "rejection code").
|
FIY @lwshang |
github-actions
bot
added
the
interface-spec
|
🤖 Here's your preview: https://c3z4p-2iaaa-aaaam-abaya-cai.icp0.io |
mraszyk
reviewed
Dec 13, 2024
Co-authored-by: mraszyk <31483726+mraszyk@users.noreply.github.com>
Dfinity-Bjoern
approved these changes
Jan 3, 2025
mraszyk
reviewed
Jan 7, 2025
| @@ -1757,9 +1757,9 @@ There must be at most one call to `ic0.call_on_cleanup` between `ic0.call_new` a | |||
|
|
|||
| This deducts `MAX_CYCLES_PER_RESPONSE` cycles from the canister balance and sets them aside for response processing. | |||
|
|
|||
| If the function returns `0` as the `err_code`, the IC was able to enqueue the call. In this case, the call will either be delivered, returned because the destination canister does not exist, returned due to a lack of resources within the IC, or returned because of an out of cycles condition. This also means that exactly one of the reply or reject callbacks will be executed. | |||
| The returned `err_code` is always one of `0`, `1`, `2`, and `3`. An `err_code` of `0` means that no error occurred and that the IC could enqueue the call. In this case, the call will either be delivered, returned because the destination canister does not exist, returned due to a lack of resources within the IC, or returned because of an out of cycles condition. This also means that exactly one of the reply or reject callbacks will be executed. | |||
There was a problem hiding this comment.
The returned
err_codeis always one of0,1,2, and3.
Are we sure that the implementation does not start producing the new code 6 for "unknown" in some cases in the future?
There was a problem hiding this comment.
Well we obviously can never be sure that the implementation won't start ignoring the spec but I can't think of a reason why a synchronous error would be raised for unknown reasons.
There was a problem hiding this comment.
Discussion in the interface spec meeting:
- Currently there is inconsistent behavior in messages sent to the IC management canister, where in case of an invalid candid payload, the canister would trap. (Which is inconsistent with what happens if invalid candid is sent to another canister.)
- For the same case for ingress messages, we would fail with a
4. - If we ever wanted to clean up this behavior, this would mean we would want to return a
4synchronously.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Strengthen the specification of
ic0.call_performas discussed in the interface spec meeting. Also unify the naming of reject codes (previously was also "rejection code").Thank you for your contribution to the IC Developer Portal. This repo contains the content for https://internetcomputer.org and the ICP Developer Documentation, https://internetcomputer.org/docs/.
If you are submitting a Pull Request for adding or changing content on the ICP Developer Documentation, please make sure that your contribution meets the following requirements:
.mdxfile format to support the previous two components./sidebars.js, otherwise, it will not appear in theside navigation bar.
.github/CODEOWNERSfile isfilled with new documents that you added. This way we can ensure that future Pull Requests are reviewed by the right people.