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.
Environment
@shopify/cli@4.6.0Summary
POST /account/loginsubmitted 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
What we've tried
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.