Stuck in "Psalm: starting" #1
Comments
|
Hi Shane, thanks for your feedback. I've only recently forked this project to get it working for my company so you are one of the first to try it outside of our specific case. I'm happy to work with you to try and get it working for your app too. On looking into this, I see that my assumption about the debug mode was incorrect. It was only showing output when actually debugging the extension, which isn't very useful for the end-user. I've pushed an update to fix that. Debug output should now show in the Output tool window. So now you should get useful info about why it is not working to narrow things down. Add this to your settings.json to enable debug output: Also in the update (1.0.3) I've:
Let me know if any of this helps to narrow in on the cause of the issue Kind regards, |
|
Sorry, seems to be slow to publish the new version to VSCode marketplace today. Still listed as 1.0.2. Has pushed but not yet reflected. Should be available shortly all being well |
|
@plotbox-io Thanks for the quick response! I'll keep my eye out for the new version and will update once I've retested. |
|
No problem @shaneparsons. I've actually ended up bumping a couple versions to get it resolved (now at 1.0.5). It was being blocked in the extension verification step as I had added a shortUrl in the readme.md and was detected as suspicious. Anyway, should be sorted now :D |
|
The added logging is definitely helpful: |
|
OK so it looks like the docker container is unable to talk to the host via the special domain Alternatively, to make host.docker.internal work, see the config that's needed on your docker-compose.yml file(s): To debug further, you can bash in to the docker container (something like Let me know if that helps! |
|
I can ping that ip fine
Is there anything I need to do to expose that port, or anything along the lines? EDIT: that second use of ping wasn't valid... |
|
Yeah, it's definitely that But if I remove |
|
Hi again Shane. I'm out of office today so not at a PC but here's my thoughts:
I'll be back in the office tomorrow so can have a proper think through this. Let me know if you find anything else out. Thanks for your patience in working through this, will be good to make the extension more robust for others. Kind regards, |
|
Hey Richard, sounds good. It might also be worth mentioning that the host machine I'm on is actually a remote Linux server that I access through SSH. Shouldn't make a difference in the end, but maybe there's a slight difference as far as ports go, or something else along the lines... I do use the built in remote SSH plugin though, so it's as if I'm on the machine directly. |
|
It does sound on the surface quite likely that the fact you are running via a remote linux server is related to the problem. To make sure I understand fully (so I can replicate):
Does that sound correct? |
|
Hi again Shane. So I did a bit of experimenting with the assumptions listed in my last comment (running VSCode in 'remote ssh mode' to a virtual machine over an exposed SSH port) and it seemed to work without any real issues. The remote machine had to have:
As I hit each of the above, I added some better debugging output for when the docker-compose sub-command fails so we get some error output rather than silence in these failure scenarios. I've pushed a new version (1.0.6) with the added debug output - please could you try again with it and let me know if you see any errors? Kind regards |
|
Hey Richard, here's the output from the latest attempt: OutputLooking further into the error now... As far as my environment goes:
The box is hosted on AWS and is always running. I simply just tap into it when I launch vscode or ssh in. Let me know if you need further clarification on anything! |
|
Perhaps this is an upstream issue? Maybe related to psalm/psalm-vscode-plugin#176 (comment)? |
|
Thanks Shane. OK so it's still the issue with the container unable to talk to the listener (running on the box). It's odd because we've already seen that we can ping the box IP from inside the box container. So it has to be either:
(Could you just double check that you ran the Let's see if we can rule some out to narrow things down... Possibility 1
Possibility 3 Possibility 2 |
Not sure on that. Although the upstream has moved on a fair bit it seems from the fork that this fork is made from, you have to remember that the code is working perfectly fine for my team's docker dev configuration. So there must be a subtle environmental difference in the mix somewhere between yours and ours that we need to root out. It is a bit of a tricky one though.. |
Hmm, so it looks like P.S. I double checked the |
|
Interesting. There is clearly something blocking your container's ability to talk via a port to it's host in general. I saw this stack overflow just now and it made me think.. Could your container and the box both be sharing the same network (and thus sharing the same ports causing some sort of conflict). I.e., do you set the network_mode of "host" in docker-compose.yml? Or is there anything different about the networking configuration of your docker-compose.yml file(s)? We are using the default 'bridge' mode and expose only a couple of ports to the host (the box in your case) such as port 80 and port 443 |
|
I don't see any references to Here's the [
{
"Name": "mono_default",
"Id": "1c03ce82c25332061772cce91cd728117b38b0ad94dbe54e8d0f77a3bab83f86",
"Created": "2022-06-22T20:36:09.40449613Z",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.20.0.0/16",
"Gateway": "172.20.0.1"
}
]
},
"Internal": false,
"Attachable": true,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"0da5d4c6cad4f0369c2307dfa4c5f265800802cc442bcdc51fe60413722fa4a2": {
"Name": "dme_dme-app_1",
"EndpointID": "1262346f555a17ae60a74644b57b55005e43b6606a7a403580d9efef7a0b373a",
"MacAddress": "02:42:ac:14:00:11",
"IPv4Address": "172.20.0.17/16",
"IPv6Address": ""
}
},
"Options": {},
"Labels": {
"com.docker.compose.network": "default",
"com.docker.compose.project": "mono",
"com.docker.compose.version": "1.26.0"
}
}
]Here's the output of |
|
Going back to your other suggestion: There are a lot of apps / containers running w/ what I imagine are outdated docker configs at this point, so I'm not sure about the feasibility of upgrading the versions... I can enquire if we end up determining that that's the likely issue here though. |
|
Hi Shane. I was thinking about this at the weekend and, as this is likely some sort of edge case relating to the docker networking, I think the most robust solution is to add support for bypassing the need for the container to communicate with the host directly and instead communicate via the general internet. To achieve this, I've pushed a new version with support for using 'ngrok' as an alternative to the 'dockerHostDomainOrIp' setting. Now, when It all seems to be running fine on my setup so was hoping you could give it a try and see if it solves things for you. Let me know! Kind regards, |
|
Hey man, great idea on ngrok! Just gave it a few tries. The first complained about not being able to connect to OutputPerhaps some new uncaught exception? |
I think this must have still been an old version of the extension or else the ngrok setting was not getting picked up maybe. In any case, sounds like you got past that
Hmm, must be the ngrok connect command failing. I'll see if I can maybe handle errors in that part a bit better. In meantime, could you check for errors using this technique please to see if any information is there that could be useful? Thanks |
|
New version up. Essentially added a try/catch around the ngrok initialisation code. Hopefully if you try with this new version you might get some output as to why it is not working in your enviroment (the box). Might be worth trying to run ngrok on your VM box manually using the traditional CLI tooling. Could you try using the ngrok cli to start a tcp connection on some random port (see [here](ngrok tcp 1234)) and see if it works or if there is some issue there. I think that can help us rule some things out. Thanks for your ongoing efforts in working with me on this! Regards, |
|
Getting this output from the plugin now I did install ngrok and was able to get it running in my box though: DetailsI was also to get it running w/ the docker command: Details |
|
Thanks for the information @shaneparsons. Hmm, that is a bit frustrating (but still progress!) So we know that there is no issue per se with initialising ngrok on the box, just that when we try to do so via the extension / Javascript library, it has an error.. I've updated again. I realised I didn't output the stack trace or the error name to the debug output on failure, only the message. This other info might help lead us to the reason for the failure. Please could you try again and report if anything else useful shows in the output? Finally, if you would like, and feel comfortable doing so, it might help if you could debug the extension directly. I realise this is a bit of an ask but it is proving hard for me to reproduce these issues myself. It is actually super simple to get set up to test the extension in a debugging mode:
All the code is in We might be able to learn something by using breakpoints to dig into the ngrok library a little and see what the core problem is. The connect function lives here: |
|
Sounds good! I'll try to find some time to debug further later today. |
|
Not too much more useful unfortunately... I'm gonna try debugging on my end as you suggested and will let you know if I make any progress. |
|
I'm having trouble getting any of the breakpoints to work... I'm wondering if it's because I have the plugin cloned locally, and I'm trying to test from within my box? Should I have cloned the plugin to the box instead? |
|
Ah, I think I know why it was failing. I was testing again using remote ssh into my Ubuntu VM and got this: Looks like I just happened to already have signed up for an ngrok account on my local so I never got this message.. Now that I see the exact sub-type for the error, I can better handle the exception to provide debug output going forward. I'll test now and see what the best process for signing up is.. Might be possible to add an extra config param for ngrok user credentials and some blurb in readme. |
|
Hi Shane. I've puished a new update that adds |
|
Woo, it's alive!! There were a few attempts in (in between first success and current success) where I was getting Thanks for all the time you spent working on this with me man! It's definitely going to be part of my every day workflow. |
|
Fantastic news! Yeah, for my first OSS issue, this one was a doozie alright haha Glad it is working for you now Shane :) Best, |
I followed the setup steps to the best of my ability, but the extension is stuck in a "Psalm: starting" state... Here's my config:
settings.json
Some more details about my environment:
8.1.7) is running in a container calleddme-app(details below)4.23) and Xdebug (3.1.5) are both running / working in that containerpsalm/psalm-language-server/psalm.xmlare present both locally and in the containersrc/directory (i.e../vendor/bin/psalm src/), which is also in that containerdocker-compose (relevent parts)
main:
override:
dockerfile (relevent parts)
composer.json (relevent parts)
I'm not sure if I just have part of my config wrong, or if something else is not set up right? Psalm does work outside of this plugin, so environment wise everything is good.
I recently set up a similar phpstan plugin by using a
binCommandparameter:settings.json
php-dmeis a bin command fordocker-compose run --rm dme-app "$@"Perhaps we need something like that here as well? Maybe something like this already exists and I'm just missing it?
Any help would be greatly appreciated!
The text was updated successfully, but these errors were encountered: