Repository navigation
[Bug]: theme dev proxy 502 on POST /account/login (regression of #3963?) #8480
Description
Environment
| CLI version | @shopify/cli@4.6.0 |
| Node | v24.14.1 |
| OS | macOS 15, also reproduced on Ubuntu 24.04 in GitHub Actions |
| Shop | Shopify Plus, staging store on a password-protected primary domain |
Summary
POST /account/login submitted to the local theme dev server (127.0.0.1:9292) fails at the CLI proxy with a 502 Bad Gateway, before the request reaches Shopify. This blocks any local automated flow (Playwright, WebdriverIO, curl) that needs a real customer session — the login form itself is unusable.
Looks like a possible regression of the (closed) #3963 which stated "It should work now no matter the version".
Error output
```
Failed to proxy request to /account/login with status 502 (Bad Gateway).
URL: https://.myshopify.com/account/login?_fd=0&pb=0
TypeError: fetch failed
at Object.processResponse (node:internal/deps/undici/undici:12793:20)
at node:internal/deps/undici/undici:13181:23
at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
at node:internal/deps/undici/undici:17409:7
at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
at async Object.handler (file:///.../@shopify/cli/dist/chunk-Q7BOSHWX.js:7:6357)
at async Server. (file:///.../@shopify/cli/dist/chunk-Q7BOSHWX.js:7:9903)
```
Repro
- `shopify theme dev --store --theme --store-password `
- From any HTTP client: `POST http://127.0.0.1:9292/account/login\` with the standard storefront login form fields.
- The CLI logs the 502 above; the client sees a 502 response.
What we've tried
- Both Playwright's `page.request.post` and real form submission via a browser navigation. Both fail identically — the failure is at the proxy, not the client.
- Downgrading to `@shopify/cli@3.84.1`: this specific 502 does not occur, but the CLI then crashes with the (also known-broken) "Theme ID mismatch" bug during theme sync, so login can't complete for other reasons.
- Bypass attempt: POST direct to the primary storefront domain and transplant the resulting `_shopify_essential` cookie onto `127.0.0.1`. Theme dev issues a new `_shopify_essential` on every proxied response and overwrites the injected value, so the logged-in session never reaches Shopify.
Impact
Any team running functional/end-to-end tests against `theme dev` that need a real customer session cannot do so today. The workaround suggested in similar older threads — pushing to a real dev theme and hitting the preview URL — is unworkable at CI scale for stores that hit the theme cap.
Ask
Whether the proxy's `fetch failed` path is a known/tracked regression, or if there's a supported configuration we're missing to keep POST → cross-domain-redirect flows working through 4.6.0.
Activity
balkashynov commentedon Oct 14, 2026
Would a small PR improving the terminal diagnostic be useful here? On current main (
6844a6ce),createFetchErrorpreserves the original fetch error, but the banner formatter shows its stack without the nested transport code. Different failures can therefore produce the sameTypeError: fetch failedoutput.I have a two-file draft that appends recognized codes, for example
Transport error codes: UND_ERR_SOCKET, to the existing terminal banner. It follows a boundedError.causechain, deduplicates codes, and excludes nested messages and unknown codes. Existing status, request ID, URL and error identity are preserved.I reproduced the diagnostic gap with real loopback HTTP servers that return oversized headers or close before response headers. Seven regression tests fail without the change; all 22 focused tests pass on Node 22.12.0, 24.1.0 and 26.1.0. The 793-test theme suite, build, type-check, lint and scoped unused-code check pass on macOS ARM64.
This does not establish the cause of the login failure reported here; I have not reproduced it against a Shopify store. I also reviewed #8746 and #8530: they address header limits and proxy transport, and #8746 includes browser error-page output. This draft focuses on the shared terminal banner. Linux/Windows CI and maintainer review are still pending.
Would this diagnostic be a useful separate contribution alongside that work?