`pi update --self` gives up after one transient latest-version connection failure

[whyhkzk]

What happened?

pi update --self sometimes fails with:

Error: Could not determine latest pi version: fetch failed

The self-update path makes one request to https://pi.dev/api/latest-version. A transient connection failure stops the update immediately. The message shown to the user is only fetch failed. The useful network errors remain in error.cause.

Steps to reproduce

I ran the request used by getLatestPiRelease() in fresh Node.js processes on several servers in mainland China and the US. Proxies were disabled for all tests.

• Mainland China: 13 failures in 56 requests.
• US: all 16 requests succeeded.
• Failures ended after about 0.55 seconds with AggregateError: ETIMEDOUT, containing two IPv4 ETIMEDOUT errors and two IPv6 ENETUNREACH errors.
• On four affected hosts, disabling autoSelectFamily and using IPv4-first made all 24 requests succeed.

The failures occur during Node's dual-stack connection race: IPv6 is unreachable, while both IPv4 candidates can time out within their per-address attempt windows.

In three cases where the first request failed, an immediate retry in the same Node.js process succeeded. This suggests that a single retry can often recover from this failure mode.

Expected behavior

Retry the latest-version request once when pi update --self hits a transient connection failure such as ETIMEDOUT. If it fails again, surface the underlying cause. The startup version check should remain unchanged.

I'm happy to send a fix.

Version

0.80.7

[github-actions]

This issue was auto-closed. All issues from new contributors are auto-closed by default.

Maintainers review auto-closed issues daily and reopen worthwhile ones. Issues that do not meet the quality bar in CONTRIBUTING.md will not be reopened or receive a reply.

If a maintainer replies lgtmi on one of your issues, your future issues will stay open. If a maintainer replies lgtm, your future issues and PRs will stay open.

See CONTRIBUTING.md.

[prayag0one4]

I traced this locally and the failure path appears to go through getLatestPiRelease() in version-check.ts.

getLatestPiRelease() performs a single fetch() to https://pi.dev/api/latest-version with no retry logic. Any network error propagates to getSelfUpdatePlan(), which wraps it as:

Could not determine latest pi version: fetch failed

The reporter's data suggests this can happen relatively frequently under some network conditions, particularly with Node's dual-stack connection race when IPv6 is unreachable and IPv4 attempts time out during address selection windows.

A retry in the same process often succeeds immediately, which matches the behavior described in the issue.

One possible approach would be to retry getLatestPiRelease() once for transient network failures such as ETIMEDOUT, ECONNRESET, ENETUNREACH, or EAI_AGAIN, while keeping the startup version check behavior unchanged.

Happy to work on an implementation if this direction makes sense.

[petrroll]

I wonder, are there possibly more http calls exposed to this, maybe the new checks / rebuilds of model registry?

[whyhkzk]

I wonder, are there possibly more http calls exposed to this, maybe the new checks / rebuilds of model registry?

Yes, the failure happens at connection setup, below the HTTP layer, so any Node fetch() can hit the same class of error. The catalog requests (/api/models/providers/:provider) have no retry either. But they're a separate call chain: pi update --self never creates a ModelRuntime, and background refresh falls back to cached or static models, so failures there are non-fatal.

My read of #6647 is that a retry means something different in each case. Retrying a compaction replays an LLM call: it costs tokens and adds latency, and the user sees it. Tying it to the agent retry settings makes sense. Retrying the version check just resends a cheap, idempotent GET.

So I'd prefer to keep this issue small, one immediate retry of the version request in getSelfUpdatePlan. That fix doesn't need a shared retry layer; if catalog refresh ever turns out flaky in practice, it can adopt the same small pattern on its own.

[petrroll]

Yeah, I actually wanted to link this to 6647 but then removed the comment about it because I think there are at least two substantially different kinds of requests which should likely be handled entirely differently and possibly on a different layer.

You have an agent operation (e.g. 6647 or some of the already existing retries for standard loop) where the errors can be raw http/network errors but also just failures of the endpoint and which should be probably re-tried on some higher semantic level (such as they are right now).

And then you have all the other management http calls (mainly towards pi's infra (version check, now the new model catalogue revuilds, ..., but possibly also other provider catalogues, ...). And this should probably be retried on immediate layer, think just standard fetch-retry or p-retry.