# Error 404 - ingress\_expiry not within expected range

**URL:** <https://forum.dfinity.org/t/error-404-ingress-expiry-not-within-expected-range/19803>\
**Category:** Developers\
**Created:** [May 5, 2023, 7:05pm UTC](https://forum.dfinity.org/t/error-404-ingress-expiry-not-within-expected-range/19803 "2023-05-05T19:05:31Z")\
**Posts on this page:** 18\
**Page:** 2

<div class="post-metadata">

**Author:** ![bruno353](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/bruno353/32/15709_2.png) [@bruno353](https://forum.dfinity.org/u/bruno353)\
**Post date:** [September 29, 2024, 3:32pm UTC](https://forum.dfinity.org/t/error-404-ingress-expiry-not-within-expected-range/19803/21 "2024-09-29T15:32:05Z")

</div>

> [@Gwojda](#):
>
> m home where i dont have IP

Yeah, I also had similar problems when trying to interact with only IPv4 servers.

---

<div class="post-metadata">

**Author:** ![peterparker](https://avatars.discourse-cdn.com/v4/letter/p/b9bd4f/32.png) [@peterparker](https://forum.dfinity.org/u/peterparker)\
**Post date:** [October 2, 2024, 8:29pm UTC](https://forum.dfinity.org/t/error-404-ingress-expiry-not-within-expected-range/19803/22 "2024-10-02T20:29:41Z")

</div>

Another follow-up: [https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762)

---

<div class="post-metadata">

**Author:** ![Snassy-icp](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/snassy-icp/32/15536_2.png) [@Snassy-icp](https://forum.dfinity.org/u/Snassy-icp)\
**Post date:** [October 6, 2024, 10:58am UTC](https://forum.dfinity.org/t/error-404-ingress-expiry-not-within-expected-range/19803/23 "2024-10-06T10:58:06Z")

</div>

We also saw this error, when deploying to mainnet using dfx v0.24.0.

Specified ingress\_expiry not within expected range: Minimum allowed expiry: 2024-10-05 22:11:19.931428435 UTC, Maximum allowed expiry: 2024-10-05 22:16:49.931428435 UTC, Provided expiry: 2024-10-05 22:11:00 UTC

The error was consistent every time we tried. It immediately went away when downgrading to dfx v0.23.0.

Our canister sits on subnet: e66qm-3cydn-nkf4i-ml4rb-4ro6o-srm5s-x5hwq-hnprz-3meqp-s7vks-5qe

---

<div class="post-metadata">

**Author:** ![xalkan](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/xalkan/32/16076_2.png) [@xalkan](https://forum.dfinity.org/u/xalkan)\
**Post date:** [October 6, 2024, 1:46pm UTC](https://forum.dfinity.org/t/error-404-ingress-expiry-not-within-expected-range/19803/24 "2024-10-06T13:46:34Z")

</div>

We’re using dfx v0.22.0, but the ingress expiry issue persists — are you having a better experience with v0.23?

---

<div class="post-metadata">

**Author:** ![jennifertran](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/jennifertran/32/11558_2.png) [@jennifertran](https://forum.dfinity.org/u/jennifertran)\
**Post date:** [October 6, 2024, 11:26pm UTC](https://forum.dfinity.org/t/error-404-ingress-expiry-not-within-expected-range/19803/25 "2024-10-06T23:26:12Z")

</div>

For you, please review this:

> [@Subnets with heavy compute load: what can you do now & next steps](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762):
>
> Hi everybody! In the recent weeks, we’ve seen the demand for computation on ICP significantly increase. This is of course great news, but also leads to some challenges. We now see that there are quite some subnets that are running at or almost at maximum compute capacity. This means that canisters have to wait for their turn to compute and therefore messages are processed with much higher latency. You may notice ingress messages get rejected with an error saying “timed out waiting to start execu…

---

<div class="post-metadata">

**Author:** ![jennifertran](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/jennifertran/32/11558_2.png) [@jennifertran](https://forum.dfinity.org/u/jennifertran)\
**Post date:** [October 6, 2024, 11:28pm UTC](https://forum.dfinity.org/t/error-404-ingress-expiry-not-within-expected-range/19803/26 "2024-10-06T23:28:07Z")

</div>

Can you upgrade your agent and report back on what happens? Can you please remind me what subnet are you on? This would very much help with troubleshooting.

FYI: This is a known issue on the subnets listed here:

> [@Subnets with heavy compute load: what can you do now & next steps](https://forum.dfinity.org/t/subnets-with-heavy-compute-load-what-can-you-do-now-next-steps/35762/19):
>
> Small update: the next replica version that DFINITY will propose ([link](https://forum.dfinity.org/t/proposal-to-elect-new-release-rc-2024-10-03-01-30/35797)) will include changes to the scheduler and the round limits, so both of the potential short term improvements that I mentioned in the first post. This means that we may see some improvements on the busy subnets next week.

---

<div class="post-metadata">

**Author:** ![peterparker](https://avatars.discourse-cdn.com/v4/letter/p/b9bd4f/32.png) [@peterparker](https://forum.dfinity.org/u/peterparker)\
**Post date:** [October 7, 2024, 4:21am UTC](https://forum.dfinity.org/t/error-404-ingress-expiry-not-within-expected-range/19803/27 "2024-10-07T04:21:03Z")

</div>

> [@jennifertran](#):
>
> Can you upgrade your agent and report back on what happens?

That’s not OP issue (I had contact in PM). Let’s hope the new replica improves issues a bit.

---

<div class="post-metadata">

**Author:** ![xalkan](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/xalkan/32/16076_2.png) [@xalkan](https://forum.dfinity.org/u/xalkan)\
**Post date:** [October 7, 2024, 8:53am UTC](https://forum.dfinity.org/t/error-404-ingress-expiry-not-within-expected-range/19803/28 "2024-10-07T08:53:49Z")

</div>

We’re using agent v2, but the ingress expiry issue remains…

And yes, our current subnet is among the failing ones: [3hhby-wmtmw-umt4t-7ieyg-bbiig-xiylg-sblrt-voxgt-bqckd-a75bf-rqe](https://dashboard.internetcomputer.org/subnet/3hhby-wmtmw-umt4t-7ieyg-bbiig-xiylg-sblrt-voxgt-bqckd-a75bf-rqe)

---

<div class="post-metadata">

**Author:** ![YAP](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/yap/32/33025_2.png) [@YAP](https://forum.dfinity.org/u/YAP)\
**Post date:** [October 7, 2024, 9:24am UTC](https://forum.dfinity.org/t/error-404-ingress-expiry-not-within-expected-range/19803/29 "2024-10-07T09:24:51Z")

</div>

@jennifertran  
The error “Specified ingress\_expiry not within expected range” has nothing to do with the subnet load, but with the time the agent uses when submitting requests.

@xalkan  
can you give me a call example where you keep seeing this behavior so I can try to reproduce?

---

<div class="post-metadata">

**Author:** ![peterparker](https://avatars.discourse-cdn.com/v4/letter/p/b9bd4f/32.png) [@peterparker](https://forum.dfinity.org/u/peterparker)\
**Post date:** [October 7, 2024, 9:32am UTC](https://forum.dfinity.org/t/error-404-ingress-expiry-not-within-expected-range/19803/30 "2024-10-07T09:32:16Z")

</div>

> [@YAP](#):
>
> The error “Specified ingress\_expiry not within expected range” has nothing to do with the subnet load, but with the time the agent uses when submitting requests.

The agent-js has been patched. Has long as version v2.1.1 is not used, there is no issue on that side to my knowledge.

---

<div class="post-metadata">

**Author:** ![xalkan](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/xalkan/32/16076_2.png) [@xalkan](https://forum.dfinity.org/u/xalkan)\
**Post date:** [October 7, 2024, 9:58am UTC](https://forum.dfinity.org/t/error-404-ingress-expiry-not-within-expected-range/19803/31 "2024-10-07T09:58:02Z")

</div>

It isn’t easy to reproduce because it does not happen every time. It is kind of random, but I can see in the [tyron.io](http://tyron.io) app logs that it keeps happening:

 ![image](https://us1.discourse-cdn.com/flex023/uploads/dfn/original/3X/a/c/ac7d6ec5208e8fefaf53a8d833d74f0ab884ce6b.png)  
 ![image](https://us1.discourse-cdn.com/flex023/uploads/dfn/original/3X/3/d/3d16b8f61fcf1e4069b247560d17dcbdc96d1508.png)

The issue lies in the seconds timeframe; could you use rounded minutes instead?

To try to reproduce this call, you could use the `get_account` function in [DFINITY Canister Candid UI](https://a4gq6-oaaaa-aaaab-qaa4q-cai.raw.icp0.io/?id=ehubr-iyaaa-aaaap-ab3sq-cai), e.g. `get_account("bc1pce7w7gspc04uvj4ddnfu5k30tpc9h4ekt88tt6ekvt66prdhjt8s90max0", false)`, or use the UI at [tyron.io](http://tyron.io) connecting your UniSat wallet.

---

<div class="post-metadata">

**Author:** ![YAP](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/yap/32/33025_2.png) [@YAP](https://forum.dfinity.org/u/YAP)\
**Post date:** [October 7, 2024, 1:45pm UTC](https://forum.dfinity.org/t/error-404-ingress-expiry-not-within-expected-range/19803/32 "2024-10-07T13:45:43Z")

</div>

Thanks, Xalkan. I have been able to reproduce this successfully. Right now, I don’t fully understand what is happening there. I’ll try to talk to some more people about it, but not all of them are awake yet, so don’t hold your breath 🙂

---

<div class="post-metadata">

**Author:** ![YAP](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/yap/32/33025_2.png) [@YAP](https://forum.dfinity.org/u/YAP)\
**Post date:** [October 7, 2024, 7:18pm UTC](https://forum.dfinity.org/t/error-404-ingress-expiry-not-within-expected-range/19803/33 "2024-10-07T19:18:39Z")

</div>

News 🙂

We found a bug in the agent-js implementation.  
Consider a call `c` with `requestid_c` and `expiry_c`.  
The agent currently keeps using `expiry_c` when making `read_state` requests for `requestid_c` instead of using `expiry_r` representing current time + some DELTA.

We are working on a fix.

On subnets with low load that’s usually no issue, because typically the response for the request has been computed before the difference between those times becomes problematic. On subnets with high load, it can happen that a call `c` has been received and even started processing (both before the ingress expiry `expiry_c`), however, in the meantime the subnet time is greater than `expiry_c` and thus `read_state` requests must use a higher expiry `expiry_r`.

So my initial reaction that this has nothing to do with load was wrong. This agent behavior would only be seen on highly loaded subnets.

---

<div class="post-metadata">

**Author:** ![peterparker](https://avatars.discourse-cdn.com/v4/letter/p/b9bd4f/32.png) [@peterparker](https://forum.dfinity.org/u/peterparker)\
**Post date:** [October 7, 2024, 7:34pm UTC](https://forum.dfinity.org/t/error-404-ingress-expiry-not-within-expected-range/19803/34 "2024-10-07T19:34:49Z")

</div>

Wait, is that another new additional bug in agent-js, or are you talking about the one that was ‘fixed’ by reverting a change from v2.1.1 and released in [v2.1.2](https://github.com/dfinity/agent-js/releases/tag/v2.1.2) last week?

---

<div class="post-metadata">

**Author:** ![anon74414410](https://avatars.discourse-cdn.com/v4/letter/a/85f322/32.png) [@anon74414410](https://forum.dfinity.org/u/anon74414410)\
**Post date:** [October 7, 2024, 7:40pm UTC](https://forum.dfinity.org/t/error-404-ingress-expiry-not-within-expected-range/19803/35 "2024-10-07T19:40:52Z")

</div>

This is a “new” (has been present for a long time) bug. This is for the case where greater than 4 minutes (or whatever the expiry was set to) have elapsed since an update was submitted, and the `read_state` request polling itself will start to time out, without ever learning whether the `update` was successful or rejected

---

<div class="post-metadata">

**Author:** ![peterparker](https://avatars.discourse-cdn.com/v4/letter/p/b9bd4f/32.png) [@peterparker](https://forum.dfinity.org/u/peterparker)\
**Post date:** [October 7, 2024, 7:44pm UTC](https://forum.dfinity.org/t/error-404-ingress-expiry-not-within-expected-range/19803/36 "2024-10-07T19:44:14Z")

</div>

> [@anon74414410](#):
>
> This is a “new” (has always been present) bug

Gotcha. Thanks for the clarification.

---

<div class="post-metadata">

**Author:** ![anon74414410](https://avatars.discourse-cdn.com/v4/letter/a/85f322/32.png) [@anon74414410](https://forum.dfinity.org/u/anon74414410)\
**Post date:** [October 7, 2024, 7:46pm UTC](https://forum.dfinity.org/t/error-404-ingress-expiry-not-within-expected-range/19803/37 "2024-10-07T19:46:37Z")

</div>

Solving it also won’t resolve the general issue of `system` time being out of sync with `subnet` time. The specific bug Yvonne just described is scoped to `read_state` requests and polling, and wouldn’t address initial `queries` or `calls` being immediately rejected due to replica drift or system time misconfiguration.

For that, we’ll need a way to get the latest certified `subnet` time without first agreeing on that time, and then using it to construct the expiry. Preparing to solve this broader problem is where the 2.1.1 bug was introduced.

---

<div class="post-metadata">

**Author:** ![MalithHatananchchige](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/malithhatananchchige/32/10925_2.png) [@MalithHatananchchige](https://forum.dfinity.org/u/MalithHatananchchige)\
**Post date:** [October 13, 2024, 3:41pm UTC](https://forum.dfinity.org/t/error-404-ingress-expiry-not-within-expected-range/19803/38 "2024-10-13T15:41:25Z")

</div>

I was using JUNO to deploy a website and I started experiencing this issue. so far my hack was

### Sets expiry 5 minutes from now

`export INGRESS_EXPIRY=$(($(date +%s) + 300)) `

[Previous page](https://forum.dfinity.org/t/error-404-ingress-expiry-not-within-expected-range/19803.md?page=1)
