Hmmm…I think this works but I’m not sure if I can do this from motoko. @claudio is there a way to check a future to see if has been fulfilled without actually awaiting it? I guess I can use a timer before the await and populate a variable elsewhere. If it does work and since almost any ICRC2 canister should return those functions very quickly I shouldn’t have to loop too many times. rawrand() forces a round wait doesn’t it? In other situations, I’ve called a known xnet call(like checking a balance on ICP) for the same effect. I’ll have to inspect which is cheaper.
Just so I’m clear…My property checker canister would be timing out the call context so my Main canister would not be in danger…but what about the property checker? If it has made a call to a bad actor in one of these requests and then the bad canister call goes out of context…does the canister and replica drop it thus removing the hanging reference that would block upgrade of the checker? And what about the queue? Is it an attack vector to call one of those a bunch of times such that the queue gets full? If I’m timing out and the canister stops taking requests then I guess they’d eventually clear but it still seems it could get ddosed. If this canister only listens to my other main canister then I guess I can rate limit there.
The next question would be a cross-over to my Using NnsCanisterUpgrade Proposal types question which would be if the NNS can uninstall a canister through proposal. I think if I track the wasm and maybe query the upgrade history from inside the canister I can give myself security even if I let the controller be the anon identity, but it might ‘feel’ better to others if on the NNS could do it.