This feature includes the v3 synchronous call API! Calls to mainnet are able to bypass polling using the new endpoint
The HttpAgent allows you to set and read replicaTime, which it will maintain information about in order to handle disagreements between the client and replica about time.
Fixes and improvements for the useAuthClient library
Full release notes: Release Release 2.1.0 · dfinity/agent-js · GitHub
What does that mean? Is this supposed to fix the issue reported here? Is this an automatic feature or one that requires the consumer to take action? If the latter, could you share a code snippet?
If you agree on the time with the replica and set it on the HttpAgent, it will allow the agent to set an ingress expiry that the replica will accept.
The agent does not do this automatically, as there is no secure way to fetch the time from the replica without first agreeing about time. In the future, this may be something we can do automatically, when the IC has a feature that would support this flow.
Sorry, I’m not sure I understand.
I will not say the issue is resolved, nor will I share a snippet for how to apply it, because there is no way to do that today that meets my standards for security
Could you get the IC time from several replicas and do some form of agreement, to get an approximation? The more replicas you query the more likely it is that you won’t be tricked in accepting some time far in the future (which is what I assume worries you).
that sounds like a reasonable idea, although I believe one of Kai’s concerns with this is around latency. creation of an http agent is async, but the instance is effectively unusable until the time can be established, leaving any application in a partially (or fully) unusable state as well.
how much latency would you estimate is incurred by querying multiple replicas? could that latency be minimized with a different design?
Is there any documentation on how to use this feature? Or is it the exact same interface as before and it just automatically uses v3?
If it makes a v3 calls to /api/v3/canister/…/call first and then does multiple read_state calls to
/api/v2/canister/…/read_state then what could be the reason?
Also, the response headers of the v3 call contain a field x-request-id:. Is that expected?
UPDATE: Question has been answered. The feature simply isn’t live yet on mainnnet. The v3 endpoint exists but behaves as v2 for most subnets. We just need to wait until next week.
Those queries can be made in parallel (as well as the verification of the signed responses that one gets) so that should be in the order of hundreds of milliseconds I’d say — but there may be more that’s needed (e.g. fetching the verification keys for the nodes; I don’t know if those are included in the reply/certified by some means)
Okay so without using set replica time i get this error
Error: ReplicaTimeError: Specified ingress_expiry not within expected range: Minimum allowed expiry: 2024-09-25 13:57:00.580809774 UTC, Maximum allowed expiry: 2024-09-25 14:02:30.580809774 UTC, Provided expiry: 2024-09-25 13:57:00 UTC
Then i update my code to do something like this:
And get this error:
Error: Call was rejected:
Request ID: 865668fc95d239160f91b15e9b625205a296c5ff09dbdc4a7f7e9afd49fec51f
Reject code: 2
Reject text: Ingress message 0x865668fc95d239160f91b15e9b625205a296c5ff09dbdc4a7f7e9afd49fec51f timed out waiting to start executing.
Can someone explain how i am meant to be using replicaTime to avoid these errors?
Hello Jake
The root of the first error you encountered is the fact that a client’s time can be ahead or behind the replica’s time which receives the message. Moreover the time certified by the subnet’s nodes can differ from both those times as well. We are aware of the problem and we’re discussing different options to improve the situation. We should be able to communicate a more concrete plan soon.
For the second problem, please note that the ingress expiry ensures that a subnet will not start executing a message if the subnet time is higher than the expiry. It is not guaranteed though, that a message will be executed if its ingress expiry is within the bounds of the replica that got it first.
Since I don’t know the agents’ code, I cannot answer your question about the code.
So when i do a standard query call the agent works fine.
But this issue comes when i make an update call to the canister. This canister then makes an intercanister call to the management canister to create a new canister and install code onto it
A follow-up on this release: