Completely unpredictable behavior of xDebug - who faced it?

Question

xdebug

Guys, the completely unpredictable behavior of xDebug - sometimes it works, sometimes it doesn't work.
Below is a link to the video, everything is very clear there (3 minutes, do not be too lazy to look, I broke my whole head) Bottom
line: Installed Vagrant Homestead 7 box Deployed Laravel 5.7 IDE PHPStorm 2018.2
PHP 7.2, xDebug 2.6 Then configured xDebug according to the manuals. It is weird in its own way - it slows down at a breakpoint, offers a transition through variables. The transition is made, but the variables in the lower window are not reflected. Then I put another box - instead of Homestead 7 I put ScotchBox 3.5, there I upgrade to php 7.2 and install xDebug 2.6, deploy the same laravel.




Here, in general, the situation is stupid - it sometimes shows local variables, sometimes it does not.
And through time clings.
Further, without any laravel, I try to test on bare php - the same story, either catches or skips some variables. Although on bare php it catches more often.
What does it look like? What is crooked here - PHPStorm is not configured that way, or maybe this IDE is just stupid? Or is it xDebug 2.6 with php 7.2 being weird?..
Here is the video:
https://youtu.be/lwU69g79jYI

Answer 1

The point is to synchronize data between the vagrant and your local directory, set up deploy correctly in a storm, I recommend using ssh, but I recommend turning off virtualbox synchronization, on the contrary, it is very slow, especially for tests when creating cache files

Answer 2

That's how much they tried to woo me all sorts of crap like dockers, vagrants - so many problems later ..
Spend half an hour, collect everything from the packages and don't know problems

Answer 3

I understand that you have a problem after editing? There may be a problem with the synchronization delay of the edited file or some caches. And I'm also not sure if it's correct to interrupt xdebug, as you do in the video by clicking on the stop button, it's better to let the script run to the end.