-
Notifications
You must be signed in to change notification settings - Fork 20
[FINAL] feat: Allow accepting and burning cycles in replicated queries #313
Conversation
🤖 Here's your preview: https://ojuyi-5iaaa-aaaak-qcnsq-cai.icp0.io/docs |
@mraszyk I realized while working on the replica side of things that since certain parts of the canister's state, more specifically its system state, will change during replicated query execution, the canister version will be bumped. I suppose this is fine but do you think we should make any amendments in the spec? Or is the current section on canister version "vague" enough to allow for this? |
The spec says that "The system can arbitrarily increment the canister version also if the canister's code, settings, running status, and memory do not change." so we're technically fine, but we might want to update the section on "Canister version" to mention the case of replicated queries explicitly. |
Made an update. See my last commit and let me know if it's ok. |
Co-authored-by: mraszyk <[email protected]>
Superseded by dfinity/portal#3760 |
Given a previous change that introduced formally the concepts of replicated and non-replicated queries, we can now extend the spec to allow accepting and burning cycles in replicated queries. This allows for creating reasonable business models for canisters by requiring callers in replicated mode to always make payments for accessing their endpoints.