feat: use cycles ledger to create canisters #3473
Conversation
…-new-canisters-using-the-principals-cycles
sesi200
changed the title
…-new-canisters-using-the-principals-cycles
| } | ||
|
|
||
| let cycles = with_cycles.unwrap_or(CANISTER_CREATE_FEE + CANISTER_INITIAL_CYCLE_BALANCE); | ||
| let result = agent |
There was a problem hiding this comment.
Please set created_at_time, so that it's an idempotent operation, and wrap this call in retry logic. This will reduce the likelihood of burning cycles creating a canister but not storing the canister id.
There was a problem hiding this comment.
I'm setting and logging the created_at_time now so the result will be recoverable. I don't think it makes sense to add a loop because there is no error for which a retry really makes sense (except for whatever the agent can retry on its own).
There was a problem hiding this comment.
Though it is possible to handle all of this by making the user retry their command (this time specifying --created-at-time and altering the command to create or deploy a single canister), in a case where we have an idempotent operation, in my opinion it's better to handle that retry in code.
As for determine when to retry, you are correct: it is difficult. A guess is AgentError::TimeoutWaitingForResponse() | AgentError::TransportError(_), here: https://github.com/dfinity/sdk/blob/master/src/dfx/src/lib/retryable.rs#L6.
Regarding "whatever the agent can retry on its own", the agent does not retry TransportError because it can't.
(See https://github.com/dfinity/agent-rs/blob/main/ic-agent/src/agent/http_transport/reqwest_transport.rs#L88 for an example, and up the call stack). It can't because after sending the initial request, there exists a class of errors for which it can't know if the server received the request and is executing it or not, and the agent doesn't know if the request is idempotent or not.
Relying on the agent's retry mechanisms also means relying on those mechanisms to be correct. They may or may not be. For example, Agent's fn wait doesn't retry if fn poll returns an Err, and fn poll will return an error right away in the case of connection timeout when making the read_state call.
Given the above, what do you think?
There was a problem hiding this comment.
The idempotency argument makes sense. I'll use retryable for now and if we find a better heuristic we can always impove it
…-new-canisters-using-the-principals-cycles
Co-authored-by: Eric Swanson <[email protected]>
…-new-canisters-using-the-principals-cycles
…-new-canisters-using-the-principals-cycles
sesi200
deleted the
SDK-1173-dfx-deploy-canister-create-create-new-canisters-using-the-principals-cycles
branch
Description
This PR makes dfx use the cycles ledger to create canisters when no wallet is configured.
Fixes SDK-1173
How Has This Been Tested?
Added e2e
Checklist: