[Bug]: Xdebug with trigger causes 502 Bad Gateway

mjblacker commented 3 months ago

Platform

Windows

Operating system version

Windows 10 22H2

System architecture

Intel (x86)

Herd Version

1.6.1

PHP Version

No response

Bug description

When xdebug is enabled with trigger based debugging it will try to change the port for the fastcgi daemon by adding 100 to the base port. (There is a config option for this but doesn't do anything from what I could find)

The windows php-cgi processes are already running on the base port + version number so adding 100 just gives a 502 Bad Gateway error as there is no fastcgi available on the port trying to be accessed.

To fix: Edit the debug.conf file in the ~.config\herd\config\pro\nginx folder and either negate the map for detecting the xdebug cookies or change the debug ports to match the base ports.

Steps to reproduce

Turn on xdebug but do not enable for all requests, use a browser plugin to trigger the debug session as needed.

Relevant log output

nginx-error.log:

2024/05/14 16:49:08 [error] 13592#19976: *1 connect() failed (10061: No connection could be made because the target machine actively refused it) while connecting to upstream, client: 127.0.0.1, server: xxxx.test, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9183", host: "xxxx.test"

mpociot commented 3 months ago

@mjblacker do you use Herd Pro?

mjblacker commented 3 months ago

@mjblacker do you use Herd Pro?

No. Followed these instructions: https://herd.laravel.com/docs/windows/1/advanced-usage/xdebug Only enabled the mode though not the start commands.

Already had a workflow for using xdebug so wanted to use it as I would if I was using local, docker, artisan serve.

Might also be an issue with all requests IF you are using the browser extension like me as the nginx rule is just based on the cookie.

Plugin I'm using: https://chromewebstore.google.com/detail/xdebug-helper/eadndfjplgieldjbigjakmdgkmoaaaoc

The reason the "pro" file is included is from the base nginx file in the config includes it and the valet file.

From the bottom of the ~/.config/herd/config/nginx/nginx.conf

include "C:/Users/xxx/.config/herd/config/pro/nginx/*.conf";
include "C:/Users/xxx/.config/herd/config/valet/Nginx/*.conf";
include herd.conf;

mpociot commented 3 months ago

Right - that's a bug in Herd in this case. With Herd Pro we automatically switch to the debug FPM process based on the triggers. But as you're not using Herd Pro, the pro config should not be loaded.

So you can fix it yourself right now by removing/commenting out the line that includes the pro configuration file.

dev-idkwhoami commented 3 months ago

So i have the same issue i followed the instructions in the Herd docs to activate xdebug.

Then i found this issue and tried commenting out the "pro" inclusion, but that was a bad tip since the nginx variable herd_sock is being mapped in "C:\Users\.config\herd\config\pro\nginx\debug.conf"

So all that did was break Herd even more ^^

Edit:

I just bought Pro just for the fun of it and with Pro this actually just works 🤨

mjblacker commented 3 months ago

So i have the same issue i followed the instructions in the Herd docs to activate xdebug.

Then i found this issue and tried commenting out the "pro" inclusion, but that was a bad tip since the nginx variable herd_sock is being mapped in "C:\Users.config\herd\config\pro\nginx\debug.conf"

So all that did was break Herd even more ^^

My original solution to fix (as I posted this bug after figuring it out) Edit the debug.conf file in the ~.config\herd\config\pro\nginx folder and change the debug ports to match the base ports.

Glad that it's all working with Pro though.

beyondcode / herd-community