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.
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?