Skip to content
This repository has been archived by the owner on Nov 19, 2024. It is now read-only.

[FINAL] feat: Allow accepting and burning cycles in replicated queries #313

Closed
wants to merge 7 commits into 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]>
@mraszyk
Copy link
Contributor

mraszyk commented Nov 15, 2024

Superseded by dfinity/portal#3760

@mraszyk mraszyk closed this Nov 15, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants