m2-assistant[bot]
commented
3 years ago Hi @JAADOBE. Thank you for your report. To help us process this issue please make sure that you provided sufficient information.
Please, add a comment to assign the issue: @magento I am working on this
- Join Magento Community Engineering Slack and ask your questions in #github channel.
dobooth
dshevtsov
Bug report
This merchant outlines what they believe to be Documentation issues with the links listed in the comment:
"Here's what is missing / wrong: SSH tunnel The documentation describes that for Staging and Production in the Pro plan, a single SSH tunnel must be set up using the cluster name in the target hostname (s. https://devdocs.magento.com/cloud/howtos/debug.html#pro-debug). This incorrect. In fact, as Najib has pointed out, you have to create a tunnel for each node of the cluster as you cannot make sure that your request will end up on a specific node. The documentation has to be changed to reflect this, otherwise other people will run into the same problem.
PhpStorm setup In Step 4 of the documentation on how to set up PhpStorm (https://devdocs.magento.com/cloud/howtos/debug.html#phpstorm), the suggestions for the fields Host and Port are wrong. Instead of "localhost", the public hostname of the server has to be inserted here. Instead of Port 80, 443 has to be inserted.
Actual debugging The documentation (https://devdocs.magento.com/cloud/howtos/debug.html#pro-debug) states that after successfully starting a debug session - using the XDEBUG_SESSION_START parameter - you should be able to send requests and debug them until you terminate the session using the XDEBUG_SESSION_STOP parameter. This does not work due to the multiple nodes in the cluster. The session is started on one node (the one that receives the parameterized request) but any request that follows may or may not hit that node, thus the whole point of starting a session that triggers a cookie is worthless. In fact if you want to be sure to get a debug session every request must have the XDEBUG_SESSION_START parameter. I'm actually not even sure that a cookie was returned upon starting a session, so this might also be an issue.
Considering Fastly When Fastly is enabled on Staging or Production in Pro plan, you have to add a cache breaker to the URL (some query parameter with a varying value) when starting / stopping an xdebug session, otherwise Fastly will return something it had cached previousely, resulting in no debug session being started. This was never considered in the documentation but badly needs to be added.
Xdebug browser extension The documentation states that for debugging web requests (https://devdocs.magento.com/cloud/howtos/debug.html#webrequests) you have to use a browser extension, e.g. Xdebug helper. With debugging enabled via that extension, I could not get a debug session to start at all. Quite the opposite was true, when i disabled debugging via that extension or simply removed the extension, I was able to start a session. My guess is that the configuration of
xdebug.idekeyon the servers is simply empty.Multiple domains Our staging environment has multiple domains, one for every active store view. It seems to me, that only the main domain (staging.pinoshop.com in our case) can be used to debug as I was unable to start a debugging session when I sent a parameterized request to any other domain (e.g. de.staging.pinoshop.ch). Is this expected behaviour? If so, it should be mentioned in the documentation.
That seid, I don't have the impression that anyone has ever tested all of that stuff on a Pro Staging or Production before otherwise he/she would have hit the very same wall that I have hit. Honestly for a product that is supposed to be enterprise level this is really poor.
Regards Jean-Bernard Valentaten"