fix: local connectivity check fails on valid networks (302 redirect)

[vikasiwp]

Problem

instawp local create fails with "Cannot reach WordPress download servers" even when the user has working connectivity and can reach the WordPress download servers (task 858b3035).

Root cause

checkPlaygroundConnectivity() (src/lib/local-env.ts) probed downloads.w.org with a HEAD fetch. That host 302-redirects to wordpress.org/download/, and fetch follows redirects by default. Following the redirect is the fragile part:

• On some networks the HEAD-follow errors out (the reporter's environment).
• A GET-follow downloads the full body of wordpress.org/download/ and times out (reproduced here on Node 22.22 → ETIMEDOUT).

The tools that work for the reporter — curl -I and Node https.get() — succeed precisely because neither follows the redirect. The check only needs to know the host answers, so following the redirect is both unnecessary and the source of the failure.

Fix

Add redirect: 'manual' to both reachability probes (downloads.w.org and the downloads.wordpress.org fallback). Any response — including the 302 — proves the host is reachable, which is exactly what the check tests. The existing "no throw ⇒ reachable" logic is unchanged; this is the smallest correct change (2 lines + a comment).

Note: the originally-suggested "switch HEAD→GET" would have made it worse — GET follows the redirect and downloads the whole target page (times out). redirect: 'manual' fixes it independent of method.

Verification

Reproduced on Node 22.22:

probe	result
HEAD default (follow)	fails on reporter's net
GET default (follow)	ETIMEDOUT (downloads target body)
HEAD + redirect:'manual'	OK 302, fast
GET + redirect:'manual'	OK 302, fast

Patched checkPlaygroundConnectivity() returns null (reachable). Cross-model review (GLM-4.6): no blocking issues. Full vitest suite couldn't run in the sandbox (partial dep install — read-only npm cache), but this change touches no existing test and adds no type surface (redirect is a standard RequestInit field).

Next step (human): /code-review ultra <PR#> before merge.

[claude]

Claude encountered an error —— View job

---

I'll analyze this and get back to you.

[vikasiwp]

QA: PASS ✅

Env: local build from PR head · InstaWP/cli PR #8 fix/local-connectivity-redirect @7a7b6fc · Node v22.22.0 · Linux

Criteria: instawp local create must get past the network check on a network with working connectivity — i.e. NOT print "Cannot reach WordPress download servers" — and proceed to create/start the Playground site.

Result — step by step

1. Checked out PR head, npm ci + npm run build. Confirmed the fix is in the compiled output (dist/lib/local-env.js): both reachability probes now use method:'HEAD', redirect:'manual'.
2. Ran node dist/index.js local create --name qaTest --no-open --background:

   → Creating local WordPress site "qatest"...
   ✓ Instance "qatest" created
   # Starting WordPress latest with PHP 8.3...
   ✓ Running in background (PID: 286566)
     Site:     http://127.0.0.1:9400
     WP Admin: http://127.0.0.1:9400/?instawp-login
   

   → Passed the network check (no "Network check failed" / "Cannot reach WordPress download servers"), created the instance, and launched Playground.
3. Server came up fully — server.log: Ready! WordPress is running on http://127.0.0.1:9400 (6 workers); curl → HTTP 302 (WP redirect). Browsed the site — a real, freshly-installed WordPress renders:

Why the fix is correct (direct probe evidence on this box)

Comparing the old (follow) vs new (redirect:'manual') fetch, same box/network:

manual  https://downloads.w.org          => status 302   (clean, no throw)  ← new code
follow  https://downloads.w.org          => status 200
manual  https://downloads.wordpress.org  => status 302   (clean, no throw)  ← new code
follow  https://downloads.wordpress.org  => THREW TypeError: fetch failed   ← old code fragility

The HEAD-follow of the 302 actually threw here on downloads.wordpress.org, reproducing exactly the class of failure this PR removes. With redirect:'manual' both probes return a clean 302, which is all the check needs to prove reachability.

Repro-before-fix: Not reproduced on this box's network — the primary probe (downloads.w.org) HEAD-follow happens to return 200 here, so main also passes on this network. The bug is network-dependent (as noted in the PR); the follow-throw above on the secondary host demonstrates the underlying fragility, and the fix makes the check robust to it.

Note: the repo has pre-existing tsc type errors (missing @types/* for chalk, conf, better-sqlite3, etc.) unrelated to this PR — tsc still emits JS and the CLI runs fine. Sandbox torn down (instawp local delete qatest).

— QA