Please note that some commits may be excluded from this release if they’re not relevant, or not modifying the GuestOS image. Additionally, descriptions of some changes might have been slightly modified to fit the release notes format.
To see a full list of commits added since last release, compare the revisions on GitHub.
Features:
20321d102 Execution,Interface,Message Routing: Support for best-effort messages in CanisterQueues (#879)
6765fd498 Execution,Interface,Networking: Reduce slice limit for install_code messages in system subnets (#1401)
bfba799c6 Interface: Define RejectCode::SysUnknown and error codes (#1380)
c3a180c94 Interface: pull out canister-based implementations of Ledger/CMC (#1386)
656d7a64a Interface,Message Routing: load number of pages from disk in merge strategy (#1248)
cb9249d5d Interface,Node: Add mgmt_mac field to deployment.json (#1365)
Bugfixes:
e680d5b91 Interface( Ledger): add effective subaccount to (#1405)
002852f5a Interface,Networking: revert the old error string when outcall response is bigger than the limit (#1411)
The two SHA256 sums printed above from a) the downloaded CDN image and b) the locally built image, must be identical, and must match the SHA256 from the payload of the NNS proposal.
Please note that some commits may be excluded from this release if they’re not relevant, or not modifying the GuestOS image. Additionally, descriptions of some changes might have been slightly modified to fit the release notes format.
To see a full list of commits added since last release, compare the revisions on GitHub.
The two SHA256 sums printed above from a) the downloaded CDN image and b) the locally built image, must be identical, and must match the SHA256 from the payload of the NNS proposal.
We apologize for any inconvenience caused by a correction submitted after the initial proposal:
Recently, in a pull request made by IDX, the directory /gitlab-ci/ was renamed to /ci/. Unfortunately, this change was not reflected in time within the tooling of the DRE repository. The fix is now available, but proposals 132481 and 132482 were already submitted using the old paths.
Specifically, in the verification instructions, the path:
Since all other aspects remain unchanged and the verification script itself is unmodified, we believe this minor oversight should not warrant rejection of the proposals.
We sincerely apologize for any inconvenience and hope the community will accept the corrected link for the verification scripts.
We have already corrected the instructions in the forum posts in this thread, but the NNS proposals themselves are immutable so cannot be corrected.
cc @zenithcode@Lorimer@wpb@ZackDS
I was just about to post a “why’s the 5d25ae6 commit missing in the proposal summary?”, then I noticed that it’s been reverted as part of the same release, and therefore excluded from the proposal summary. Thanks for doing this.
It was also useful to be able to refer to the extend proposal summary on Github to confirm that the commit had been intentionally omitted. Thank you for continually improving release procedures. It makes a difference and is very much appreciated.
Please note that some commits may be excluded from this release if they’re not relevant, or not modifying the GuestOS image. Additionally, descriptions of some changes might have been slightly modified to fit the release notes format.
To see a full list of commits added since last release, compare the revisions on GitHub.
The two SHA256 sums printed above from a) the downloaded CDN image and b) the locally built image, must be identical, and must match the SHA256 from the payload of the NNS proposal.
Please note that some commits may be excluded from this release if they’re not relevant, or not modifying the GuestOS image. Additionally, descriptions of some changes might have been slightly modified to fit the release notes format.
To see a full list of commits added since last release, compare the revisions on GitHub.
The two SHA256 sums printed above from a) the downloaded CDN image and b) the locally built image, must be identical, and must match the SHA256 from the payload of the NNS proposal.
Last two proposals are due to the Subnet `lhg73` is stalled
We are basically applying the same change on top of the latest elected versions, so that we can roll out the new versions together with the change.
Since there is only a single change in the proposal, it should be quick and easy to review. We are hoping for a quick review process so that we can roll out these versions already this week, and then hopefully proceed with a regular rollout next week.
Verified removal of an unwanted / deprecated assert
code changes are in accordance with release notes on the proposal
Observation in build:
Ran the verification step and verified that hash mentioned in proposal payload, hash fetched from CDN, and hash generated from local build matches.
Thanks @Sat. Presumably the removed assert (below) does not hold true anymore, and resulted in an unhandled panic that crashed the subnet?
- if let Some(state_changes) = &canister_state_changes {
- let requested = state_changes.system_state_changes.removed_cycles();
- // A cleanup callback cannot accept and send cycles.
- assert_eq!(requested.get(), 0);
- }
Does this mean that a cleanup callback can now accept and send cycles? I’m curious if this relates to a discussion from last week →
Any extra context you’re able to provide will be useful for evaluating the appropriateness of removing this assertion (without replacing it with some more graceful handling and/or logging of the erroneous state).
Update: Somehow I missed the answer that @dsarlis already gave on the other thread
Hey @sat and @lara - Just saw a new proposal 132548. Sorry, I am a little confused since the earlier proposal 132547 is also same. Are we supposed to review both the proposals?
They’re both proposals to apply the same commit, but the commit is applied on different branches. At the moment the canister snapshots feature hasn’t been deployed to all subnets. There’s a compile-time feature flag that switches it on and off (depending on the deployment target). Given this, we’ve recently been getting two IC OS proposals per week (one with the flag turned on, and one with it turned off, but both proposals containing the same set of changes otherwise).
Yes, it’s necessary to verify both proposals (the base source code is different so the build hashes are different, which need verifying).
Proposal 132548 is applied on top of the prior release that has the feature flag turned off (see ‘This release is based on changes since’ in the proposal summaries).
Proposal 132547 is applied on top of the prior release that has the feature flag turned on.
Indeed, thanks for clarifying that Lorimer. I thought it was obvious so didn’t explain it in the earlier post, but clearly it deserved a sentence or two more.
Hashes match, the only change is the removal of deprecated assert from the handle_wasm_execution_of_cleanup_callback function that handles the execution of a cleanup callback in the context of a canister’s execution. It applies canister state changes, processes the callback’s result, and finishes the execution.
Voted yes to adopt both proposals.
Both proposals passed the build verification and the only change is to remove an assertion that is no longer applicable, so I have voted to adopt both proposals.
