“http request failed because http request(POST) to https://ic0.app:443/api/v2/canister/62lf3-dyaaa-aaaak-aaoka-cai/query timeout”
Getting lots of timeout!!
Why some update calls gets executed and some are getting timedout ? I dont think so if there are any flaws in my code …
But still i want to know the reason why some update calls gets timeout? Even if there is no queue of pending update call…
Is there a possibilty that even a single update call to a canister gets timeout , due to any reason?
Yes; it can take several seconds for the subnet to reach consensus. That is why all update APIs take a Waiter type in Rust to distinguish between ‘extremely long’ and ‘inordinately long’ - 60s is usually used in DFINITY code as a default timeout. If you are waiting 5s you will have a lot of failed calls.
so basically , if a consensus took more then 60 seconds, Update call will get time out right?
One more thing, do consensus time depends on size of data we are updating in canisters ? (Is there any way to reduce consensus time by doing changes in update calls? or its only depend on availability of canisters on different subnets and number of calls canisters holding at time?)
Do you have any idea on how can i distinguish between extremely long calls and inordinately long calls in motoko ? so that i can change them or perform retries to prevent data loss!!
Also What you said about 5 second , i didnt get it ?
If consensus takes more than however long you’ve set as a timeout, it’ll time out. It does not depend on the amount of time the actual method call takes or how much data is changed. Timeouts are things that happen in ingress calls (i.e. through an agent), not in inter-canister calls, so Motoko wouldn’t be involved.
Also can you tell me any source where i can find out these limits over IC canisters and subnet ?
I need to know how much calls can i subnet handle before rejecting them , there must be something to prevent it from dos attack?
One more doubt, is there any way to decrease consensus time?
A boundary node sets its own rate limit, though I believe they are all configured for 100 requests per second. The time to consensus is as long as it takes for the nodes to reach consensus; it takes as long as it takes.