Inter canister call to NNS Cycles Minting Canister fails

Developers
1

Are there any known issues with inter-canister calls to the NNS Cycles Minting Canister? calling this directly work as expected, but doing to through an inter-canister call goes to a duration of 300+ seconds and ends in an error as shown below.

Specified ingress_expiry not within expected range: Minimum allowed expiry: 2024-09-17 20:28:33.133820679 UTC, Maximum allowed expiry: 2024-09-17 20:34:03.133820679 UTC, Provided expiry:        2024-09-17 20:28:00 UTC

as for the code

pub async fn test_cycles_per_icp() -> CanisterResult<u64> {
    let cycles_minting_service =
        CyclesMintingService(Principal::from_text("rkp4c-7iaaa-aaaaa-aaaca-cai").unwrap());
    let result = cycles_minting_service
        .get_icp_xdr_conversion_rate()
        .await
        .map(|(rate,)| rate)
        .map_err(|_| ApiError::bad_request().add_message("Error getting XDR conversion rate"))?;

    Ok(result.data.xdr_permyriad_per_icp)
}

The CyclesMintingService is the Rust declaration pulled from the dashboard where Service is renames to CyclesMintingService and serde_bytes::ByteBuf replaced with Vec<u8>

2

It is kind of strange to see this for inter-canister calls. I’m getting it on the client side all the time, which I would expect when my call goes to 0 compute canister that can only answer every 20 minutes or so…but very odd that an inter-canister call would not work.

If you are specifically calling a canister to kick this off and THEN it is supposed to call the cycle minting canister it is likely that you’re not even getting to the canister that hosts this code.

Up your compute allocation to 1 and things should get a bit better, but keep in mind it burns more cycles to do so.

1 Like
3

I guess what you mean is:

  • you call a canister via ingress,
  • that canister then executes the code you showed above,
  • and the ingress message gets the time-out,

correct?

Note that Catalyze canisters are on e66qm along with the “old” bob.fun canisters.

1 Like
4

It seems that @skilesare and @bjoern are both right and that Bob is causing some issues on this particular subnet but it possibly can be fixed by setting a compute_allocation.

I did an attempt to set this to 1% but this would require me to have 30T cycles available which is to costly for what this canister is doing. It would be cheaper to just deploy it to a different subnet.

to correct the above statement, Catalyze canisters don’t run on this subnet, this was a separate experimental canister.

1 Like
5

Thanks for correcting my statement above!

If your canister does not need a 30-day freezing threshold, then your compute allocation will also become significantly cheaper if you reduce the freezing threshold.

1 Like
6

Good to know! So you could lower it to like 5 days or something like that?

9

Yes, you can set it in number of seconds (see interface spec). It just means your canister will spend less time in frozen state before being deleted, but for some use cases that may be acceptable.

1 Like