-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FINAL] feat: Allow accepting and burning cycles in replicated queries #313
base: master
Are you sure you want to change the base?
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]>
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.