Handling multiple requests while debugging is awful

[lwxbr]

trafficstars

PHP version: 7.4.3 XDebug version: 2.8.1
Adapter version: ?

Your launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for XDebug",
            "type": "php",
            "request": "launch",
            "port": 9000
        }
    ]
}

XDebug php.ini config:

[XDebug]
zend_extension=php_xdebug.dll
xdebug.remote_enable = 1
xdebug.remote_autostart = 1

Code snippet to reproduce:

The problem is handle multiple requests simultaneously, I want to pause in the first request and ignore the other requests while debugging, is it possible?

PS.: Sorry to be harsh and I understand the developer's good will but I can't imagine a case of handling multiple requests at same time while using PHP with XDebug. I'm curious to see if it fits in some situation. Thank you!

[AnrDaemon]

Right now I'm dealing with a bug that only happens for certain permissions configuration, but it should not happen by the manual permissions investigation. I have to run two instances in parallel (a user that works fine and a user that does not) to see where the problem lies.

But it's impossible to switch between two debug sessions. You have to finish current one to be able to work with next one, and not any given one from the pending queue, but exactly next one.

[zobo]

Generally simultaneous debugging works quite ok. I'd need to check more specific cases like yours. You just need to select a thread to work on it. However, from what I read here I would suggest something else.

1. Set Xdebug to start debug only with a trigger. For Xdebug2 it was the XDEBUG_SESSION_START GET. or COOKIE.
2. Use two browsers, so one can have the trigger set and the other not.

[AnrDaemon]

I do use two browsers (in fact, I use two different cURL requests). I don't see how would that help.

[zobo]

The ide was:

In php.ini set

xdebug.remote_autostart=0

Then when you start the request you want to debug, do it like this:

curl http://..../path?XDEBUG_SESSION_START=vsc

This will work for Xdebug 2 but not for Xdebug 3.

Only that PHP request that has this trigger will start the debug engine and try to connect to VSCode.

I hope this help.

[AnrDaemon]

That's exactly how I'm dealing with this.

[iandunn]

If you never want to handle multiple requests, then I think you can just add this to your launch.json config:

"maxConnections": 1

One of the things the OP didn't mention, is that when new requests come in, the original request is paused and the new debug sidebar switches over to the new request. So, if you want to continue debugging the original request, you have to switch back to the first one. That gets frustrating when you have something like a "heartbeat" XHR making a new request every 30 seconds.

A potential UX improvement for that situation could be to pause the second request, and keep focus on the first request. Then if the user wants to, they can switch to the new request.

[AnrDaemon]

This became more stable in recent versions, but there's still issues I can't attribute directly to the extension. "Watch" widget sometimes become unresponsive, it will still display values of variables in it, but stops adding new expressions for evaluation. If I restart debug, all added expressions appear.

[AnrDaemon]

Also, while you have 2 sessions paused on a breakpoint, stepping one will change focus to another and back. It's somehow tolerable, when you have exactly two sessions, but when you have ten or so in queue (rarely, but happens), this become unbearable.

[zobo]

Hi! This switch over behavior seems strange. Do you think you can make a short gif/video of it? or provide me some logs. I'll try to reproduce it then. It could be because of the extension or VSCode....

Regarding watch, if you manage to catch it, open a new issue with a log and I'll be happy to look at it.

[AnrDaemon]

Do you think you can make a short gif/video of it? or provide me some logs. I'll try to reproduce it then. It could be because of the extension or VSCode....

This should be easy to reproduce. Launch 2 threads and try to step through second one. The moment IDE pauses waiting for client response, focus will switch to the first thread. When the packet arrives in second thread, it will switch back to it. You just have to be extra careful to not press buttons too eagerly.

The situation itself is quite common in my case. The main thread (web request) sends job to RabbitMQ. The worker will pick the job, perform the action and report its completion using callback URL in the job. I have a conditional breakpoint in the callback's router to debug specific request, and there could be multiple callback pings depending on the action requested (some report "progress" in addition to final result). Because callbacks are time sensitive, I have to step through them before doing more work on the main thread.