Skip to content

[Bug]: theme dev proxy 502 on POST /account/login (regression of #3963?) #8480

Open

Description

@matt-omaze

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

  1. `shopify theme dev --store --theme --store-password `
  2. From any HTTP client: `POST http://127.0.0.1:9292/account/login\` with the standard storefront login form fields.
  3. 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

  1. balkashynov commented on Oct 14, 2026

    @balkashynov

    Would a small PR improving the terminal diagnostic be useful here? On current main (6844a6ce), createFetchError preserves the original fetch error, but the banner formatter shows its stack without the nested transport code. Different failures can therefore produce the same TypeError: fetch failed output.

    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 bounded Error.cause chain, 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions