Ingress_expiry not within expected range error

hello there,
ingress_expiry not within expected error when deploy frontend canister from server ,
to create static page i sent get data request to node api and node api call my backend canister to fetch data , some pages created and in some pages it throw an error ingress_expiry not within expected range .


sometime its work well and sometime i face this error .
And on frontend my website is on article base when i try to publish the the article i face this error

2 week ago it was working well and now this error is happing.
and my time is also synced .i hope i will get authenticated solution from definity team.

1 Like

Had the same issue, but in Rust

This is a potentially known issue. Can you and @dantol29 please let me know what subnet is the canister that you are on?

1 Like
1 Like

In the latest AgentJS release, you can set a specific replicaTime. Can you please try that and see if it helps per the other thread that we’re communicating in?

1 Like

i have update its version to latest and and i don;t know to to set its value replicaTime
i have set it like
const replicaTime = BigInt(Date.now()) * BigInt(1_000_000); // Current time in nanoseconds

const agent = options.agent || HttpAgent.createSync({ …options.agentOptions ,replicaTime});
is it correct if not then reffer me how to do this. thanks

BOB ledger - https://dashboard.internetcomputer.org/canister/egjwt-lqaaa-aaaak-qi2aa-cai

1 Like

Solution for those who use rust ic-agent library:

use time::{Duration, OffsetDateTime};
use ic_agent::Agent;

let now_utc = OffsetDateTime::now_utc();
let five_seconds = Duration::seconds(5);
let time = now_utc + five_seconds;

agent.query(&ledger.id, "get_transactions")
       .expire_at(time)
       .with_arg("your args").unwrap())
       .call_without_verification().await

how i can did this in next js creating agent please need help @jennifertran
when i send request to canister it show me error like ingress expiry screenshot i mentioned above

https://github.com/search?q=repo%3Adappblock%2Fnextjs-ic-starter%20agent&type=code

Had this weird error also in a project I worked on, had this when one of my team member has deployed the project on main net and while testing on main net, rust backend and react front end.
This was the issue, Some on the internet said that the system time might be wrong. Which we checked later on, and seemed to be correct.

Ultimately, we resolved the error by deploying again on main net in my laptop, and it worked perfectly. So, I’d suggest you to do that. Not another laptop, but prolly just deploying again on the main net.

which canisiter i deploy now i send a request to backend canister which throw an error “ingress expiry” ,
is this reason can be i am send to many request to backend ? as i am creating build of nextjs and static pages and for each static page a create an actor and an send request to backend to get data? if anyone the reason than please let me know. thanks

Hi @jennifertran,

We have the same problem periodically, affecting network calls that require user to be authenticated.

Is there a fix?

Thanks,
James

1 Like

Dear Alishan and James

The root of the problem you encountered is the fact that a client’s time can be ahead of 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.

2 Likes

Thanks @yvonneanne for your response. How i can make client time ahead ? Suggest be best solution because my project is live.

1 Like

We’ve been encountering this issue quite often as well whenever we do Update calls. We’re using Motoko for our canisters.

Specified ingress_expiry not within expected range: Minimum allowed expiry: 2024-09-25 16:20:14.229894131 UTC, Maximum allowed expiry: 2024-09-25 16:25:44.229894131 UTC, Provided expiry: 2024-09-25 16:20:00 UTC

Yeah a work around would be good for now

So I deploy and it’s fine for a moment but then a few minutes later it is out of sync.

image

I think it’s not from our end its from ICP. @yvonneanne

This issue might be subnet-specific, though it’s just a guess—it could be related to the V3 release aimed at reducing end-to-end latencies ?