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:
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
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).
@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.
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?
@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?