502 errors with xDebug

Constantly getting 502 errors recently with xDebug + PHP (7 or 8) and LocalWP.

XdebugError: command is not available
at new Response (/Users/scottbuscemi/.vscode/extensions/felixfbecker.php-debug-1.14.12/out/xdebugConnection.js:77:19)
at Connection. (/Users/scottbuscemi/.vscode/extensions/felixfbecker.php-debug-1.14.12/out/xdebugConnection.js:632:20)
at Generator.next ()
at fulfilled (/Users/scottbuscemi/.vscode/extensions/felixfbecker.php-debug-1.14.12/out/xdebugConnection.js:24:58)
at processTicksAndRejections (internal/process/task_queues.js:97:5) {
code: 5
}
connection 3: read ECONNRESET

Try PHP Debug by tainsin

Link? Google isn’t turning anything up.

Sorry, it’s a VSCode extension

I tried a VSCode extension and I’m still getting 502 errors.

2021/05/01 06:56:02 [error] 3049#0: *555 upstream prematurely closed connection while reading response header from upstream, client: 127.0.0.1, server: , request: “GET /wp-admin/post.php?post=101175&action=edit HTTP/1.0”, upstream: “fastcgi://unix:/Users/scottbuscemi/Library/Application Support/Local/run/rxjNSoEMG/php/php-fpm.socket:”, host: “DOMAIN”, referrer: “DOMAIN/wp-admin/edit.php?post_type=shop_subscription”

(“DOMAIN” is replaced)

It happens whenever I hit a breakpoint, usually…

That’s a different error. Might try switching PHP versions, etc.

Does it happen everywhere on the site, or do you notice it only within the wp-admin? Seeing shop_subscription makes me think of a content type that would potentially be returning a lot of data, especially in the form of HTTP headers etc…

I wonder if this has to do with WP trying to return too much data for the Local Router (nginx proxy) to handle?

This might break things, but I wonder if tuning the nginx configuration for the Local Router would help? You can find that configuration file under:

~/Library/Application Support/local/run/router/nginx/conf

Curious! Thanks for the reply. Any pointers on what to focus on tuning?

I tried bumping up the buffers/etc, but still get 502 bad gateway after hitting a breakpoint. This is when the 502s are happening, sorry for not specifying better before.

I’m also seeing this in the debug console, but seemed to show up before the 502 rather than the cause of the 502:

XdebugError: command is not available
at new Response (/Users/scottbuscemi/.vscode/extensions/felixfbecker.php-debug-1.14.12/out/xdebugConnection.js:77:19)
at Connection. (/Users/scottbuscemi/.vscode/extensions/felixfbecker.php-debug-1.14.12/out/xdebugConnection.js:632:20)
at Generator.next ()
at fulfilled (/Users/scottbuscemi/.vscode/extensions/felixfbecker.php-debug-1.14.12/out/xdebugConnection.js:24:58)
at processTicksAndRejections (internal/process/task_queues.js:97:5) {
code: 5
}

I always have to remind myself the specific messages for these 5xx warnings:

502 Bad Gateway

The HyperText Transfer Protocol (HTTP) 502 Bad Gateway server error response code indicates that the server, while acting as a gateway or proxy, received an invalid response from the upstream server.
– 502 Bad Gateway - HTTP | MDN

So do you get the 502 immediately after hitting the breakpoint, or do does it show up after a bit of time while you’re investigating things within VSCode? I ask because, if it does take some time to generate the 502, then maybe the router just isn’t waiting long enough for the response.

Remember that the xdebug connection is sort of like making a request to a server and waiting a long time for the request to finish. In a production environment, you’re waiting for things like look ups to the DB. But over xdebug, the browser is just waiting for us poor devs to wrap our heads around the bug we’re investigating.

One other thing while googling – do you have multiple sessions open at one time?

This comment on a bug seems to indicate that having parallel connections might be causing the XdebugError: command is not available error you are seeing:

It’s within 1-2 seconds of hitting the breakpoint that the site throws the 502.

I don’t have multiple sessions open at once - but perhaps I have wp-admin open in the background which is running heartbeat? Is that multiple xdebug sessions or just multiple php sessions running at the same time?

That’s an interesting thing I hadn’t considered – good callout. If you try using Xdebug only on the front-end (maybe even logged out of WP), do you ever get a 502?

I’m not 100% sure. But it looks like in that linked Github issue, a better async manager was recently merged, so maybe there will be improvement in the next release of the VSCode extension?

It does seem like I’m no longer getting the debug console error, but I’m getting 502 errors and timeouts only a few seconds after hitting a breakpoint still. No idea how to get work done without xDebug breakpoints :frowning:

Logged in status doesn’t seem to affect it. Hitting a breakpoint either shows a 502 error a few seconds later, or it shows a blank screen starting wherever the processing ended. If the breakpoint was early enough in the WordPress function waterfall (not sure the right terminology), then the whole page is blank.

Have you looked at this issue? Timeouts during nginx xdebug session

My timeout value is already at 20-60 minutes, so it doesn’t seem related.

It might be related to a php bug: https://bugs.php.net/bug.php?id=63395]

But changing these settings as recommended doesn’t resolve it either.

The 502 error is what’s sticks in my mind and makes me think it has to do with the Local Router.

@scottbuscemi – as a test, can you try switching to localhost Router Mode from “Preferences > Advanced” and see if you can trigger a persistent breakpoint that way?

Doing this will have your browser directly connect to the port that’s serving the WP site and can help us zero in on where exactly the issue is happening.

If this works, it may be a good workaround in the short term, however the main limitation of this is that you can’t run the site over HTTPS.

If you’d like a little more backstory on the Local Router as well as the “Router Mode” setting, see this help doc:

I tried this, but ran into quite a bit of issues since wp search-replace was failing in the CLI and all links are pointing to the “normal” url.

Error: There has been a critical error on this website.Learn more about troubleshooting WordPress. There has been a critical error on this website.

I’ll have to try this out with a different and perhaps less-complex install to see if I can debug it any further.

The 502 (Bad Gateway) status code indicates that the server while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request. The “proxy server” is a system or router that acts as a gateway between your computer and the internet.

How to fix?

Perform a hard-refresh in your browser. On Macs, this is done by pressing Cmd + Shift + R.

If you are surfing the Web and see this problem for all Web sites you try to visit, then either 1) your ISP has a major equipment failure/overload or 2) there is something wrong with your internal Internet connection e.g. your firewall is not functioning correctly. In the first case, only your ISP can help you. In the second case, you need to fix whatever it is that is preventing you reaching the Internet.

This problem is due to poor IP communication between back-end computers, possibly including the Web server at the site you are trying to visit. Before analysing this problem, you should clear your browser cache completely.

Finally, restart your computer/networking equipment. Some temporary issues with your computer and how it’s connecting to your network could be causing 502 Bad gateway errors, especially if you’re seeing the error on more than one website. In these cases, a restart would help.

This reply isn’t relevant to the xDebug issue. However, I haven’t been seeing this issue as of late so it may have been resolved in a previous release.

1 Like

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.