Skip to content
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

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

dsarlis
Copy link
Member

@dsarlis dsarlis commented Jun 12, 2024

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.

Copy link

github-actions bot commented Jun 12, 2024

🤖 Here's your preview: https://ojuyi-5iaaa-aaaak-qcnsq-cai.icp0.io/docs

@dsarlis dsarlis changed the title feat: Allow using some of the cycles APIs in replicated queries feat: Allow accepting and burning cycles in replicated queries Jun 12, 2024
spec/index.md Outdated Show resolved Hide resolved
spec/index.md Show resolved Hide resolved
@dsarlis dsarlis marked this pull request as ready for review June 12, 2024 14:06
@dsarlis dsarlis requested a review from a team as a code owner June 12, 2024 14:06
@Dfinity-Bjoern Dfinity-Bjoern changed the title feat: Allow accepting and burning cycles in replicated queries [FINAL] feat: Allow accepting and burning cycles in replicated queries Jun 13, 2024
@dsarlis
Copy link
Member Author

dsarlis commented Jul 9, 2024

@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?

@mraszyk
Copy link
Contributor

mraszyk commented Jul 15, 2024

@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.

@dsarlis
Copy link
Member Author

dsarlis commented Jul 15, 2024

@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.

spec/index.md Outdated Show resolved Hide resolved
Co-authored-by: mraszyk <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants