Error with composite query calls. All are being rejected

I just implemented composite queries into my motoko code. When I attempt to call the composite query function, I’m getting the following error message:

Call failed:
Canister: hxx6x-baaaa-aaaap-qaaxq-cai
Method: getCanisterCyclesBalances (query)
"Status": "rejected"
"Code": "CanisterReject"
"Message": "Canister nl6hn-ja4yw-wvmpy-3z2jx-ymc34-pisx3-3cp5z-3oj4a-qzzny-jbsv3-4qe not found"

here is the code thats producing this error:

public composite query(msg) func getCanisterCyclesBalances() : async MainTypes.CanisterCyclesBalances{
        let backendCyclesBalance = Cycles.balance();
        let ic : IC.Self = actor "aaaaa-aa";
        let {cycles = frontendCyclesBalance } = await ic.canister_status({ canister_id = Principal.fromText(daoMetaData_v2.frontEndPrincipal) });
        return {frontendCyclesBalance; backendCyclesBalance };
    };

and here is the function signature for the ic.canister_status method that I’m calling:

public type Self = actor {
        canister_status : query { canister_id : canister_id } -> async canister_status_response;
};

can someone help me resolve this issue?

You are asking for the canister status of daoMetaData_v2.frontEndPrincipal. It looks like this is the user’s principal, not a canister. Canister principals are much shorter than the one in the error message

thanks for responding so fast @Severin. the principal in the error message is the Subnet’s principal ID. the value of daoMetaData_v2.frontEndPrincipal is fkkq7-siaaa-aaaap-qaaya-cai. I can confirm that it is a canister principal.

I believe its calling the subnet’s principal because I defined the ic actor using "aaaaa-aa". I’m guessing that when actors are defined using "aaaaa-aa", the subnet’s principal is used as the acting principal.

also, I do know that the issue isn’t with that particular canister as I have tested other composite query functions where I make inter-canister query calls with a method from rkp4c-7iaaa-aaaaa-aaaca-cai (the Cycles Minting Canister) as the inner async method being called, and it returned the same error with rkp4c-7iaaa-aaaaa-aaaca-cai being the canister listed as not found within the error message.

Ah, that’s possible… Let me ask the execution/runtime people about that… Could be something with composite queries not working as expected with the mgmt canister

1 Like

Hi @Jesse,

The management canister’s canister_status is an update call. No update calls can be called from composite queries (only other composite queries and regular queries).

You can see the interface spec from the management canister here. There, you can see that the canister_status call is not declared a query (so it is implicitly an update call).

Hope this helps
Stefan

2 Likes

@stefan-kaestle, I’m also getting the same error when attempting to call other known query methods- namely, the get_icp_xdr_conversion_rate method within the cycles minting canister.

Call failed:
  Canister: hxx6x-baaaa-aaaap-qaaxq-cai
  Method: getCanisterData (query)
  "Status": "rejected"
  "Code": "CanisterReject"
  "Message": "Canister rkp4c-7iaaa-aaaaa-aaaca-cai not found"

I confirmed that the method is a query method via the icp dashboard (see screenshot below)

Could you send the code for that call as well.

One restrictions with composite queries is that they don’t work across subnetworks. rkp4c-7iaaa-aaaaa-aaaca-cai is the cycles miniting canister, which is in the NNS subnetwork. So that could be the problem?

1 Like

That most certainly is the problem. Thats good to know.

@stefan-kaestle this raises a question. I have some canisters that are programmatically deployed by my main.mo canister. At no point do I specify which subnet they are to be deployed to. Is a child canister guaranteed to be deployed to the same subnet as the parent canister that deployed it?

Yes, a canister always makes new canisters in same subnet.

2 Likes

For this particular call, the error is that canister_status is not a query method, so you should instead declare it with this type:

public type Self = actor {
        canister_status : { canister_id : canister_id } -> async canister_status_response;
};

(omitting query).

(See The Internet Computer Interface Specification | Internet Computer - if canister_status were a query, it would have a Candid query keyword at the end of the Candid function type.)

1 Like