How to do a cross canister query call ? For example I would like to check icrc1_balance_of to ledger canister from my canister.
I tried to use ic_cdk::call but it doesn’t work for normal queries, only for composite queries.
Can I maybe use HTTP outcalls?
If the ledger you want to check is on the same subnet you can do it with a composite query. Otherwise it is not possible in a query call.
HTTPS outcalls don’t work because aaaaa-aa:http_request is an update method
@aligatorr89 may I know where this question is coming from as this is related to ICRC-1. what’s the scenario you need the balance for?
@marc0olo , I want to query other index canister for transaction info https://dashboard.internetcomputer.org/canister/ft6fn-7aaaa-aaaaq-aacfa-cai#get_account_transactions.
Is this possible from another canister?
Example. Could issue be related to local network setup?
All canisters are on http://127.0.0.1:8080
I know canister c5kvi-uuaaa-aaaaa-qaaia-cai is working/running.
let (fee,): (u128, ) = ic_cdk::call(
Principal::from_text("c5kvi-uuaaa-aaaaa-qaaia-cai").unwrap(),
"icrc1_fee",
(),
)
.await
.expect("error");;
if the snipped you shared is part of a query function, you wouldn’t be able to call other query functions if my understanding about the information shared in the composite query docs is correct 
@Severin does that mean you’d always need to define such function as update function or make use of composite query, where you would then have to be sure that the targeted canisters all belong to the same subnet?
sidenote: I am also still learning 
Nailed it. We haven’t talked much about composite queries lately. I’m guessing with the recent mentions of subnet migration that these will get a bit less useful as you may suddenly find that the canister you were querying has migrated.
@skilesare , do you know how OpenChat implemented tipping for external ledgers?
Transfering token is easy, and happens from client → external ledger canister.
Do they commit transaction id on their canister or how do they verify the tip on that particular message happened?
this would have been my follow-up question how this will be handled once canister migration is possible (cc @mraszyk)
Great question. Is there something they do with the tip besides just do the transaction? It may be that it is all client side(with maybe a message saved in the chat stream with a tip type?) I have never used it. Typically people use the memo field to store some info as a signal to a processing canister. But if the tokens are going to a bunch of different addresses that they don’t know they need to monitor from a bunch of different ledgers that would be a processing nightmare. (You might wish you had an event pubsub system 
)
I had bug in the call, since I started to get response from another canister query endpoint.
Will leave post mortem once I fully understand what was wrong (Rust can be difficult with async calls)
The fact that composite queries to a canister fail after the callee migrates away to a different subnet is indeed a downside of the restriction that composite queries can only target canisters on the same subnet. To prevent such failures, composite queries should not cross canister groups owned by the same entity which can thereby be expected to move to a different subnet together.
It is probably a dot point to put on the canister migration roadmap to make sure the docs on how to do this are up to date and clear. Is this a setting you can set after deployment? During deployment?
I’m not sure what “setting” you refer to: when I talked about “canister groups” I didn’t have any IC settings in mind, I just wanted to characterize a set of canisters that happen to call each other and it is the canister’s responsibility to not call canisters that are owned by a different entity and thus could be migrated unexpectedly.