Proposal to elect new release rc--2024-09-12_01-30

[Lorimer]

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 →

@tim1

the current API makes it very hard to pay only for what you use (you need to specify the expected response size in advance with max_response_bytes). As a follow-up, we will revisit the API and see how to improve it so that people don’t need to do hacky workarounds anymore.

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

Subnet `lhg73` is stalled

canister_state_changes is going to be Some(changes) instead of None if the canister made changes to its state that need to be persisted (perfectly normal for a cleanup callback). The assert that used to be there was trying to check that there was no case that the canister’s cycle balance was reduced as part of those changes while executing the cleanup callback (note that we are talking during execution, obviously the canister is charged for executing the message but that happens after execution…

---

Verified both builds and voted to adopt

132548

132547

Thanks for getting the hotfix published promptly