Multiple PHPStan runs happening in parallel

I have a similar issue to this (https://github.com/swordev/phpstan-vscode/issues/11) when using this plugin.
I see many runs of PHPStan happening at the same time. Not sure if it's the same issue, but I don't see this issue on the command line.
I have max core usage for PHPStan set to 2 in my config:
parallel:
	maximumNumberOfProcesses: 2

Using PHPStan v1.11.1
vendor/bin/phpstan --version
PHPStan - PHP Static Analysis Tool 1.11.1

In theory it should kill any running processes whenever a new one is spawned. I think it should be pretty easy to figure out where it goes wrong. If you open up vscode it should do a single check. If at that point you have many running processes then it's an issue with the config not being respected. If not then something might be going wrong with the killing of processes. Can you test that for me?
Something else it could also be: are you sure your config file is being used in the checks? You can verify by checking the logs of the extension in the output panel.
You can also run phpstan with the same command you see there to test out where it's going wrong.

If I'm very careful not to save often, the extension behaves fine. It's if I'm working fast, making changes and hitting CMD+S often that the processes start to pile up and it bogs my machine down to a crawl with so many PHPStans running simultaneously.
I think the PHPStan worker processes take some time to die.
I see the 2s wait time for the main process to die, but that might not be enough in some instances.
Maybe keep a loop going to be sure the processes are dead? Also, maybe check the child (worker) processes of the main PHPStan process to be sure they're all dead before proceeding to fire up a new process?

There is indeed a 2 second timer for the process to exit gracefully. But after that a SIGTERM is sent, after which a SIGKILL is sent if it's still not behaving. Only when either the process exits or it takes 10s to exit does the extension move on and spawn a new one. I could consider bumping the 10s, but I'm not too sure if the extension will be able to be of any use if PHPStan resists being killed.
I could maybe look at the children of the main process but implementing a process-tree crawler that works cross-platform is really hard in node. Every platform has different semantics around these things.
A simpler alternative might be to get PHPStan Pro which has a watch mode that's built into the process itself. Meaning it itself watches instead of an external program (my extension in this case) spawning processes and killing them. By doing so you'll also support the creator (not me btw, I don't get anything from this endorsement). This  extension integrates with the Pro mode by showing the errors that Pro collects in your editor and by starting/stopping pro mode as you open your project.
Ideally I'd of course want to fix the issue but it seems to be worse on a mac (at least I haven't heard anyone report it on a windows/linux device yet) and I don't own a mac so I can't reproduce it.

Hi,
I don't know if it's related but sometime phpstan starts piling up project scan.
The bar show "phpstan scanning file 123/1567" (or something like that).
But I do not want phpstan to start project scan (or maybe once at startup). My projects has 1500+ files and my phpstan runs in docker. Just scanning current file is fine but maybe it's a chain effect with the dependencies ?
When it happens vscode just end up crashing on memory usage...
PS: I was not able to make phpstan server work using phpstan@docker. is there some documentation about it ?

That does sound like another issue. It's not so much piling up as it's just a single big scan happening. Sounds like the phpstan.singleFileMode setting is what you're looking for. By default this extension checks the whole project (since that's what the author of PHPStan recommends). But with that mode enabled it'll only perform checks for the current file.
The reason he recommends that is that in the long run, performing single-file checks is much slower. Since it invalidates the cache every time. That means it doesn't scan just the files that changed and its usages, but also needs to scan its dependents. So in the long run single-file-mode costs you more CPU time. If you've completed a succesful checks once, the cache will ensure checks from then on are much less heavy. But I can understand not going for complete checks on a relatively low-power machine.
I haven't used PHPStan inside docker myself so no documentation for it (yet). But you should be able to make it work by using the phpstan.binCommand setting, maybe using the phpstan.paths setting too (explanation here). There are also quite some issues on this repo discussing docker support so you might be able to puzzle it together based on those (such as #1).

I think that does sound like another issue - albeit one that we're also seeing. Project contains > 2000 files/scripts, which renders VSCode unusable for 10-15 seconds after every save as PHPStan rips through the entire project. On a machine with 10th gen i7 CPU, that does seem abnormally long.
Enabling singleFileMode does improve things marginally but there's still a considerable delay between ctrl+s and being able to navigate method definitions etc by ctrl+click on method names, for example whilst "PHPStan checking..." whirls away in the status bar. I do only see a single php process running, so it's not like it's kicked off multiple processes.
Performance is preventing us from using this on-save so we'd love to find a solution. Any help in diagnosing this, if it's not related to other the other people in this issue's experiences would be appreciated.

That does indeed sound unrelated to the extension. The performance hit probably comes from running PHPStan itself, which is spawned by the extension but since it's spawned in it shouldn't be hanging up the UI thread. If that's happening it's likely that your computer is just being maxed out. That's not surprising btw, when I run it on my own desktop PC (with a similarly powerful CPU)  it also freezes completely.  Even on that thing it takes ~20s to check ~2k files and it consumes a large amount of processing power. PHPStan is pretty demanding.
You can test this out by just running PHPStan by itself on the commandline. If it's fast, it's the extension's fault. If it's slow, then it's PHPStan itself being slow :)

I have the same as berniedurfee-renaissance on my Mac.
PHP processes piling up.
I checked the extension log files of VS Code.
In the PHPStan Client Log I noticed the following (hide the file path with ------) :
[check:23] Check started for file: ------
[check:22] Check completed for file, errors= {"fileSpecificErrors":{},"notFileSpecificErrors":[]}
[check:23] Spawning PHPStan with the following configuration:  {"binStr":"/opt/homebrew/bin/phpstan","args":["analyse","-c","------/phpstan.neon","--error-format=json","--no-interaction","--memory-limit=1G","--no-progress","------.php"],"tmpDir":"/tmp/phpstan"}
[process-spawner] Spawning process 18610 with timeout 900000
[file-watcher] Checking: Document changed
with timeout 900000 => 900 seconds I guess?
But in the extension settings the Project timeout is 300000 and the other timeout is 30000.
Maybe that timeout of 15 minutes could cause that it looks like the processes are not stopped/killed but takes longer than expected.
Let me know if I need to provide more details to help you solve the issue.

Correct that's 15 minutes. There's two timeouts:

The regular timeout that you specify. If PHPStan runs longer than this the extension tries to kill this check and reports it as failed.
This 15m timeout that is just there to ensure that there are no PHPStan zombie processes remaining. PHPStan has the tendency to leave zombies and this code will just kill whatever is alive after 15m to ensure all of those zombies are dead. You could see this as more of a fail-safe that doesn't let PHPStan gracefully exit.

(I agree that logging-wise this is very unclear, might change that in the future)

Just like to add I am also getting the same issue. I too am using docker.
Here is my config for reference:
"phpstan.rootDir": "${workspaceFolder}",
"phpstan.configFile": "build/phpstan/src.1.neon.dist,build/phpstan/src.2.neon.dist,build/phpstan/tests.1.neon.dist,build/phpstan/tests.2.neon.dist,build/phpstan/tests.3.neon.dist",
"phpstan.binPath": "/var/www/REDACTED/vendor/bin/phpstan",
"phpstan.projectTimeout": 9999999,
"phpstan.paths":{
	"${workspaceFolder}": "/var/www/REDACTED",
},
"phpstan.binCommand": ["docker", "exec", "-t", "REDACTED_api_php-1", "php", "/var/www/REDACTED/vendor/bin/phpstan"],
"phpstan.memoryLimit": "4096M",

Ah yeah that would actually very much so explain the issue. Thanks for the suggestion! Will try to fix this some time soon but since I'm currently a bit busy it might take a while.

Having this issue without using docker. I'm running VSCode using the remote ssh extension with phpstan installed. I can very easily spawn multiple processes of phpstan by rapidly saving a file, even with maximumNumberOfProcesses: 1 in my config. I'm running in single file mode.

@tedg On which platform are you using remote SSH? I've been using remote SSH into linux for quite a while now and haven't really ran into the issue myself so it would be really nice if I could find someone who can replicate the issue in a plain non-docker environment (while I dive into the docker issue on the side). Would you be willing to help me out in debugging by using a debug build that adds some logging around what processes are being killed and which aren't? That would really help a lot in debugging

@tedg On which platform are you using remote SSH? I've been using remote SSH into linux for quite a while now and haven't really ran into the issue myself so it would be really nice if I could find someone who can replicate the issue in a plain non-docker environment (while I dive into the docker issue on the side). Would you be willing to help me out in debugging by using a debug build that adds some logging around what processes are being killed and which aren't? That would really help a lot in debugging

Yup I am using linux in a non-docker env. Let me know how I can help.

Hello, came to chime in with my own voice. I'm having this issue as well, and unlike some of the other commenters I'm running in a relatively small project (Less than 300 files). I'm seeing this happen on a Windows non-docker environment. If it helps, I can say for certain that this was not an issue I was experiencing a month ago, so whatever it is is likely related to a recent change. I'm also happy to set up a debug environment on my machine to assist.

I've created a debug build that includes a bunch of logging. Probably the easiest way to view/export this is to open up the devtools in VSCode (Help -> Toggle Developer Tools), go to the console, filter on debug in the top bar and export it by right-clicking the window. To install the below zip (github doesn't allow uploading .vsix files), rename the file to .vsix, go to the extensions tab in your editor, hit the dots on the top-right, then "install from VSIX" and select the file. Thanks a lot!

Edit: As an additional point I wasn't seeing elsewhere, new php cli's aren't only opening on save. They seem to continuously pile up independently. It might be that the cli is actually closing on time but that new ones just keep opening.

Hmm could this be PHPStan spawning new workers as it's going through the files? Not too sure what could be causing that.
phpstan-vscode-3.1.14.zip

Alright so, a couple of things of note:

Because I wasn't sure what type of information would be in a debug file for this and there is sensitive information in my project, I started trying to follow your instructions by using an old side project (using the same machine as my main project). However, in this demo environment I was unable to replicate the bug.

As soon as I switched back to my main project the bug reappeared. Perhaps this bug is only present in bad configurations?

The debugger is not capturing any information.

I am however seeing the following the the console window (not sure if it's related at all):

log.ts:429  WARN Settings pattern "application.*" doesn't match any settings
log.ts:419  INFO Extension host (LocalProcess pid: 10480) is unresponsive.
localProcessExtensionHost.ts:275 Extension Host
localProcessExtensionHost.ts:276 Debugger attached.
log.ts:419  INFO UNRESPONSIVE extension host: starting to profile NOW
log.ts:419  INFO Extension host (LocalProcess pid: 10480) is responsive.
log.ts:419  INFO UNRESPONSIVE extension host: received responsive event and cancelling profiling session
log.ts:429  WARN UNRESPONSIVE extension host: 'sanderronde.phpstan-vscode' took 98.18580978301088% of 597.063ms, saved PROFILE here: 'file:///c%3A/Users/ADM~1.SCC/AppData/Local/Temp/exthost-d651ca.cpuprofile'
index.js:40

In case it's relevant, I've attached the noted file:
exthost-d651ca.cpuprofile

Just to give you some more info, all this build does is log stuff to the developer tools' console. You can then copy the text in there (and strip anything sensitive). There shouldn't be anything sensitive in there though, only "launched with configuration X" "process ID Y killed" etc.
That's interesting. Is there any difference in your configuration of the extension, or any difference in the configuration of PHPStan itself?
Just checking, do you mean the devtools? It should at the very least be dumping out some PHPStan logs, even if you don't filter on debug at the top.
Well that sounds pretty related, looks like the extension is crashing or something. Do you get this every time, do you get this only when using this version of the extension or also for the version in the store?

I could screencapture the steps to clarify things if that would help btw

Noted.
Folder structure is slightly different in the demo project. Otherwise no. I'm actually no longer even sure i am seeing the bug. I had about 15 instances of the php cli at one point but haven't seen it go into the hundreds like it had been. Debug build is working?
Oh, it shows other things, just not when filtering by debug (aside from telling me that the debugger is loaded and that xDebug isn't).
I don't get this every time. But it does happen sometimes for sure. Both with this version and store version.

I think i understood your instructions fairly well.. but if you would like to send me screencaptures to be sure you can.

Well that's interesting. Could it maybe be related to the size of the project? The bigger project has more files so it's more likely to still be running while another instance spins up? The debug build shouldn't change any functionality in theory. It only adds some logs so that it would be surprising if it somehow fixed it.
That might mean that you didn't install the provided .vsix file correctly and are just using the store version. Could that be the case? Do you see any debug-related statements in the output panel (I show it in the video).
Not too sure what this is, maybe it's not necessarily related but just VSCode complaining that the PHPStan run is taking up a lot of CPU.

An additional question, do you have the phpstan.enableLanguageServer setting enabled? That does occasionally cause some cache invalidation issues so you might want to try turning that off.
I've recorded a video to be sure everything is going right (and for you to see what it's supposed to look like when it works).
https://github.com/user-attachments/assets/fca63f50-e88c-4115-abf2-b4adfe3937be

I've done some work on the Docker issues and have made some changes:

I've added a setup wizard for easier docker (and non-docker) setup
I've made it so that, after using the new wizard, the container name is stored in settings, after which it can be used to kill the currently running processes by running kill inside of docker. That should fix the mentioned issue

I've attached a build containing these changes. (again the same goes, .zip file, rename to .vsix, drag into the extensions panel). @Sectimus can you give this build a try and see if it improves anything. Be sure to use the new setup feature so that the container name is saved in settings or it won't work.
phpstan-vscode-3.1.14.zip

personnaly i have the problem, and enableLanguageServer  is enabled, it spawn 10s of process at the same time and make wsl/vscode unresponsive

Alright I've finally managed to reproduce the problem and I've concluded that it's not really the fault of the extension but just the fault of PHPStan not properly cleaning up after itself. The reason for that conclusion is that even when the workers of 4+ previously-spawned PHPStan processes were still running, there was always just 1 parent process. This means the extension did kill the right process but PHPStan didn't pass along the kill signal to its workers. Even when just using a simple SIGINT and giving it any time it needs to pass along the signal, it doesn't.
So I've decided on another approach, which is just to look up the process tree, identify the child PIDs and kill them all manually alongside the parent. A bonus is that now the child PIDs are also stored in the zombie-killer. This zombie-killer comes into action when the editor launches (such as after a reload window), after which it will kill any PIDs that were previously registered as being PHPStan processes or workers. Previously this zombie killer would only try to kill the parent, but since it was the children that were the issue that didn't help.
I've attached a build of the extension where the issue should be fixed (at least it was for me). If any of you could give it a try I'd greatly appreciate that!
phpstan-vscode-3.1.14.zip

Thank you. I'm gonna try it today with the new version.

it doesn't work properly, it is stuck at 100%

but it looks to work anyway, with just the message stuck

by the way, when i modify phpstan.neon, it doesn't trigger a change, I must modify anything in the files to trigger a phpstan check

So far I don't have php processes stack up anymore. Yesterday kept the Activity Monitor open and the php processes were all closed after the timeout. For me all seems to work good now.

it doesn't work properly, it is stuck at 100%

Ah yeah that was indeed a bit buggy, fixed it.

by the way, when i modify phpstan.neon, it doesn't trigger a change, I must modify anything in the files to trigger a phpstan check

Fixed this too.
Here's a new build. @momala454 if you can confirm that this works I'll release this fix and at least mark the non-docker part as done.
phpstan-vscode-3.1.14.zip

And another one that includes docker-specific killing support (for anybody using docker willing to check):
phpstan-vscode-3.1.14.zip
If not I'll just ship this after shipping the other changes.

hi @SanderRonde
Thanks, it looks to have fixed the problems

actually, the status bar is ok, but i still have this issue

(maybe a stupid question but) could it be that it's correct? That your checks are actually timing out? How long does a check take when performed on the command line with no cache?

after clearing the cache (vendor/bin/phpstan clear-result-cache)
time vendor/bin/phpstan analyse -c phpstan.neon
real    0m45.646s
user    6m0.004s
sys     0m7.522s

and when running it again :
real    0m1.601s
user    0m1.275s
sys     0m0.182s

If I modify the code to add an issue, it takes only a few seconds to show me on vscode the issue reported by phpstan.
And the hover text is correct.
Then no popup for timeout shown.
However, if I do multiple modifications quickly and save between each of them, I do see the timeout popup, but the error i've added is still correctly reported. So when you kill the process, it's still counting the time spent for the killed processes and show a timeout error when it's been X seconds

Ahh that makes sense, thanks for checking. Will look into that.

Hey, another small problem unrelated. Doing a search / replace does not triger phpstan check

Hey, another small problem unrelated. Doing a search / replace does not triger phpstan check

Hmm this is actually surprisingly hard to fix. What the extension currently does is that watches all open editors and, if VSCode signals that one of them changed, queues a new check if it's a PHP file.
I could switch this to watching for file changes workspace-wide, but then the issue becomes when to trigger a check and when not to. For example a change in vendor/ shouldn't trigger one, but one in index.php should. You'd probably say "just read it from the phpstan config" but that's first of all relatively hard to parse (.neon is a file-format that's barely being used) and it's not trivial to match 1:1 what PHPStan's known list of files is. It's probably an imperfect solution but I'd suggest for now to either run a manual full-project check (> PHPStan: scan project for errors) or to use PHPStan Pro, which does include such features since it runs inside of PHPStan.
(for the future: maybe nicer to open a separate issue for this, that also allows people who have the same question to find it, while allowing me to more clearly signal the status of the issue by marking it as closed/completed etc)

it doesn't seem to be fixed, and not just about a timeout message
ps aux | grep sander -c
30
ps aux | grep sander -c
5

it was very slow to process

I've fixed the timeout issue at least.
Regarding the number of processes, I kind of have no idea what to do at this point.  If that still leaves some lingering processes it's likely to do with PHPStan ignoring kill commands or not cleaning up properly. The only alternative at this point is to pkill anything containing sanderronde but that's quite dangerous if you're running two instances of VSCode that are both scanning, or if somehow a process contains that string.
I'll just release what I've got right now and see if this improves the situation. @momala454 can you double check whether you're using the versions I posted and not the store version? I'll be releasing this one now so in a bit you'll also be able to use the store version to test.

Published as 3.2.0. Can you check whether you run into the issue still? If not I'll (finally) close this issue

Hello, thanks for the update.
It seems to fix the notification problem, but i still have 27 process open sometimes. Here is the log, it looks like it spawned multiple times phpstan
[9/9/2024, 8:54:08 AM] [client] Starting extension with configuration: {
	"phpstan.singleFileMode": false,
	"phpstan.binPath": "vendor/bin/phpstan",
	"phpstan.binCommand": [],
	"phpstan.configFile": "phpstan.neon,phpstan.neon.dist,phpstan.dist.neon",
	"phpstan.paths": {},
	"phpstan.dockerContainerName": "",
	"phpstan.rootDir": "",
	"phpstan.options": [],
	"phpstan.enableStatusBar": true,
	"phpstan.memoryLimit": "1G",
	"phpstan.enabled": true,
	"phpstan.projectTimeout": 300000,
	"phpstan.timeout": 300000,
	"phpstan.suppressTimeoutMessage": false,
	"phpstan.showProgress": false,
	"phpstan.enableLanguageServer": true,
	"phpstan.ignoreErrors": [],
	"phpstan.suppressWorkspaceMessage": false,
	"phpstan.pro": false,
	"phpstan.tmpDir": "",
	"phpstan.checkValidity": false
}
[9/9/2024, 8:54:08 AM] [client] Initializing done
[9/9/2024, 8:54:08 AM] [client] Showing one-time messages (if needed)
[9/9/2024, 8:54:08 AM] [server] Language server ready
[9/9/2024, 8:54:08 AM] [server] Language server started
[9/9/2024, 8:54:08 AM] [file-watcher] Checking: New document active active
[9/9/2024, 8:54:08 AM] [check:1] Check started for project
[9/9/2024, 8:54:08 AM] [status-bar] notification:' {"opId":0,"type":"new","tooltip":"Checking project"}
[9/9/2024, 8:54:08 AM] [status-bar] Showing status bar
[9/9/2024, 8:54:09 AM] [server] PHPStan version: PHPStan - PHP Static Analysis Tool 1.12.1

[9/9/2024, 8:54:10 AM] [file-watcher] Checking: Config change
[9/9/2024, 8:54:10 AM] [check:2] Check started for project
[9/9/2024, 8:54:10 AM] [status-bar] notification:' {"opId":1,"type":"new","tooltip":"Checking project"}
[9/9/2024, 8:54:10 AM] [file-watcher] Checking: Config change
[9/9/2024, 8:54:10 AM] [check:3] Check started for project
[9/9/2024, 8:54:10 AM] [status-bar] notification:' {"opId":2,"type":"new","tooltip":"Checking project"}
[9/9/2024, 8:54:10 AM] [status-bar] notification:' {"opId":0,"result":"Canceled","type":"done"}
[9/9/2024, 8:54:10 AM] [check:1] Check completed for project, errors= {"fileSpecificErrors":{},"notFileSpecificErrors":[]}
[9/9/2024, 8:54:10 AM] [file-watcher] Checking: Config change
[9/9/2024, 8:54:10 AM] [check:4] Check started for project
[9/9/2024, 8:54:10 AM] [status-bar] notification:' {"opId":3,"type":"new","tooltip":"Checking project"}
[9/9/2024, 8:54:10 AM] [status-bar] notification:' {"opId":1,"result":"Canceled","type":"done"}
[9/9/2024, 8:54:10 AM] [check:2] Check completed for project, errors= {"fileSpecificErrors":{},"notFileSpecificErrors":[]}
[9/9/2024, 8:54:10 AM] [diagnose-get-files] Spawning PHPStan with the following configuration:  {"binStr":"/home/bla/vendor/bin/phpstan","args":["diagnose","-c","/home/bla/phpstan.neon","-a","/home/bla/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.4/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php","-c","/home/bla/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.4/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon"]}
[9/9/2024, 8:54:10 AM] [status-bar] notification:' {"opId":2,"result":"Canceled","type":"done"}
[9/9/2024, 8:54:10 AM] [check:3] Check completed for project, errors= {"fileSpecificErrors":{},"notFileSpecificErrors":[]}
[9/9/2024, 8:54:10 AM] [check:4] Spawning PHPStan with the following configuration:  {"binStr":"/home/bla/vendor/bin/phpstan","args":["analyse","-c","/home/bla/phpstan.neon","--error-format=json","--no-interaction","--memory-limit=1G","-a","/home/bla/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.4/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php","-c","/home/bla/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.4/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon"]}
[9/9/2024, 8:54:14 AM] [file-watcher] Checking: Initial check
[9/9/2024, 8:54:14 AM] [check:5] Check started for project
[9/9/2024, 8:54:14 AM] [status-bar] notification:' {"opId":4,"type":"new","tooltip":"Checking project"}
[9/9/2024, 8:54:14 AM] [check:5] Spawning PHPStan with the following configuration:  {"binStr":"/home/bla/vendor/bin/phpstan","args":["analyse","-c","/home/bla/phpstan.neon","--error-format=json","--no-interaction","--memory-limit=1G","-a","/home/bla/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.4/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php","-c","/home/bla/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.4/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon"]}
[9/9/2024, 8:54:16 AM] [diagnose-get-files] PHPStan process exited succesfully
[9/9/2024, 8:54:18 AM] [status-bar] notification:' {"progress":{"done":0,"total":1885,"percentage":0},"opId":4,"type":"progress","tooltip":"Checking project - 0/1885 (0%)"}
[9/9/2024, 8:54:22 AM] [status-bar] notification:' {"progress":{"done":200,"total":1885,"percentage":10},"opId":4,"type":"progress","tooltip":"Checking project - 200/1885 (10%)"}
[9/9/2024, 8:54:22 AM] [status-bar] notification:' {"progress":{"done":380,"total":1885,"percentage":20},"opId":4,"type":"progress","tooltip":"Checking project - 380/1885 (20%)"}
[9/9/2024, 8:54:29 AM] [status-bar] notification:' {"progress":{"done":660,"total":1885,"percentage":35},"opId":4,"type":"progress","tooltip":"Checking project - 660/1885 (35%)"}
[9/9/2024, 8:54:58 AM] [status-bar] notification:' {"progress":{"done":1120,"total":1885,"percentage":59},"opId":4,"type":"progress","tooltip":"Checking project - 1120/1885 (59%)"}
[9/9/2024, 8:55:03 AM] [status-bar] notification:' {"progress":{"done":1160,"total":1885,"percentage":61},"opId":4,"type":"progress","tooltip":"Checking project - 1160/1885 (61%)"}
[9/9/2024, 8:55:08 AM] [status-bar] notification:' {"progress":{"done":1200,"total":1885,"percentage":63},"opId":4,"type":"progress","tooltip":"Checking project - 1200/1885 (63%)"}
[9/9/2024, 8:55:17 AM] [status-bar] notification:' {"progress":{"done":1240,"total":1885,"percentage":65},"opId":4,"type":"progress","tooltip":"Checking project - 1240/1885 (65%)"}
[9/9/2024, 8:55:21 AM] [status-bar] notification:' {"progress":{"done":1340,"total":1885,"percentage":71},"opId":4,"type":"progress","tooltip":"Checking project - 1340/1885 (71%)"}
[9/9/2024, 8:55:38 AM] [status-bar] notification:' {"progress":{"done":1885,"total":1885,"percentage":100},"opId":4,"type":"progress","tooltip":"Checking project - 1885/1885 (100%)"}
[9/9/2024, 8:55:41 AM] [check:5] PHPStan process exited succesfully
[9/9/2024, 8:55:42 AM] [status-bar] notification:' {"opId":4,"result":"Success","type":"done"}
[9/9/2024, 8:55:42 AM] [status-bar] Hiding status bar, last operation result = Success
[9/9/2024, 8:55:42 AM] [check:5] Check completed for project, errors= {"fileSpecificErrors":{"file:///home/bla/www/subscriptions.php":["Dumped type: mixed"]},"notFileSpecificErrors":[]}
[9/9/2024, 8:55:42 AM] [diagnose-get-files] Spawning PHPStan with the following configuration:  {"binStr":"/home/bla/vendor/bin/phpstan","args":["diagnose","-c","/home/bla/phpstan.neon","-a","/home/bla/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.4/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php","-c","/home/bla/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.4/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon"]}
[9/9/2024, 8:55:44 AM] [diagnose-get-files] PHPStan process exited succesfully

Hmm is there anything particular about your setup? Are you running inside docker or something? And which linux distro are you using with WSL?  I'm hoping to replicate the issue so I can more easily fix it. Maybe the killing-commands aren't available for some reason?
It did indeed spawn multiple times but if I look at the logs it does seem like the last instance was killed every time before starting a new one.

judging by the logs "check:4" have not been killed/finished ?
and check 4 and 5 are started before "diagnose-get-files" process have finished, it is normal ?
i'm using ubuntu on wsl
kill and ps are available

I've made some changes that should hopefully fix the issue. Indeed you're right that check 4 has not been killed/finished. I'm guessing that has to do with a bunch of checks being started right after each other. I've now made sure that the flurry of checks on-launch is gone.
If it's still not fixed I'll give it one more try to replicate it myself but at this point I have no clue what the issue could be and how to replicate it without going through 100 cycles of "I've added some logging here can you test this on your machine again".

thanks, it seems to work fine now. I will continue to test

This is accurate, restarting the IDE will not kill the previous processes and keep spawning new ones. I guess a cleanup is needed here indeed, maybe at the boot time of the extension. You can also notice this as it keeps spawning new "ports" for the local webserver when using the pro.

Hmm I can't really think of a reason for the processes after a composer update. There's (no longer) a file watcher other than the one watching for changes in your opened files. So changes in vendor/ shouldn't trigger anything.
Indeed correct that the processes don't stop immediately. There's a bunch of code responsible for finding any of those unwilling-to-be-killed processes and forcefully killing them. But I'm kind of unsure of what to do next if even that is not working.
Can you consistently reproduce the problem? If so I can maybe make a debug build for you that adds some logging that'll help me investigate.

yes i can reproduce.
Doing composer update didn't trigger anything apparently, but then when i modify something, it goes back to 27 processes
Log file
[9/12/2024, 11:52:17 AM] [file-watcher] Checking: Document changed
[9/12/2024, 11:52:17 AM] [check:77] Check started for project
[9/12/2024, 11:52:17 AM] [status-bar] notification:' {"opId":76,"type":"new","tooltip":"Checking project"}
[9/12/2024, 11:52:17 AM] [status-bar] Showing status bar
[9/12/2024, 11:52:17 AM] [check:77] Spawning PHPStan with the following configuration:  {"binStr":"/home/blah/blah/blah/vendor/bin/phpstan","args":["analyse","-c","/home/blah/blah/blah/phpstan.neon","--error-format=json","--no-interaction","--memory-limit=1G","-a","/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php","-c","/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon"]}
[9/12/2024, 11:52:21 AM] [status-bar] notification:' {"progress":{"done":0,"total":1891,"percentage":0},"opId":76,"type":"progress","tooltip":"Checking project - 0/1891 (0%)"}
[9/12/2024, 11:52:24 AM] [status-bar] notification:' {"progress":{"done":20,"total":1891,"percentage":1},"opId":76,"type":"progress","tooltip":"Checking project - 20/1891 (1%)"}
[9/12/2024, 11:52:24 AM] [status-bar] notification:' {"progress":{"done":200,"total":1891,"percentage":10},"opId":76,"type":"progress","tooltip":"Checking project - 200/1891 (10%)"}
[9/12/2024, 11:52:24 AM] [status-bar] notification:' {"progress":{"done":380,"total":1891,"percentage":20},"opId":76,"type":"progress","tooltip":"Checking project - 380/1891 (20%)"}
[9/12/2024, 11:52:25 AM] [status-bar] notification:' {"progress":{"done":580,"total":1891,"percentage":30},"opId":76,"type":"progress","tooltip":"Checking project - 580/1891 (30%)"}
[9/12/2024, 11:52:25 AM] [status-bar] notification:' {"progress":{"done":640,"total":1891,"percentage":33},"opId":76,"type":"progress","tooltip":"Checking project - 640/1891 (33%)"}
[9/12/2024, 11:52:27 AM] [status-bar] notification:' {"progress":{"done":660,"total":1891,"percentage":34},"opId":76,"type":"progress","tooltip":"Checking project - 660/1891 (34%)"}
[9/12/2024, 11:52:28 AM] [status-bar] notification:' {"progress":{"done":680,"total":1891,"percentage":35},"opId":76,"type":"progress","tooltip":"Checking project - 680/1891 (35%)"}
[9/12/2024, 11:52:30 AM] [status-bar] notification:' {"progress":{"done":700,"total":1891,"percentage":37},"opId":76,"type":"progress","tooltip":"Checking project - 700/1891 (37%)"}
[9/12/2024, 11:52:31 AM] [status-bar] notification:' {"progress":{"done":740,"total":1891,"percentage":39},"opId":76,"type":"progress","tooltip":"Checking project - 740/1891 (39%)"}
[9/12/2024, 11:52:33 AM] [status-bar] notification:' {"progress":{"done":760,"total":1891,"percentage":40},"opId":76,"type":"progress","tooltip":"Checking project - 760/1891 (40%)"}
[9/12/2024, 11:52:36 AM] [status-bar] notification:' {"progress":{"done":800,"total":1891,"percentage":42},"opId":76,"type":"progress","tooltip":"Checking project - 800/1891 (42%)"}
[9/12/2024, 11:52:37 AM] [status-bar] notification:' {"progress":{"done":820,"total":1891,"percentage":43},"opId":76,"type":"progress","tooltip":"Checking project - 820/1891 (43%)"}
[9/12/2024, 11:52:38 AM] [status-bar] notification:' {"progress":{"done":880,"total":1891,"percentage":46},"opId":76,"type":"progress","tooltip":"Checking project - 880/1891 (46%)"}
[9/12/2024, 11:52:39 AM] [status-bar] notification:' {"progress":{"done":900,"total":1891,"percentage":47},"opId":76,"type":"progress","tooltip":"Checking project - 900/1891 (47%)"}
[9/12/2024, 11:52:42 AM] [status-bar] notification:' {"progress":{"done":920,"total":1891,"percentage":48},"opId":76,"type":"progress","tooltip":"Checking project - 920/1891 (48%)"}
[9/12/2024, 11:52:42 AM] [status-bar] notification:' {"progress":{"done":940,"total":1891,"percentage":49},"opId":76,"type":"progress","tooltip":"Checking project - 940/1891 (49%)"}
[9/12/2024, 11:52:44 AM] [status-bar] notification:' {"progress":{"done":960,"total":1891,"percentage":50},"opId":76,"type":"progress","tooltip":"Checking project - 960/1891 (50%)"}
[9/12/2024, 11:52:45 AM] [status-bar] notification:' {"progress":{"done":1020,"total":1891,"percentage":53},"opId":76,"type":"progress","tooltip":"Checking project - 1020/1891 (53%)"}
[9/12/2024, 11:52:48 AM] [status-bar] notification:' {"progress":{"done":1040,"total":1891,"percentage":54},"opId":76,"type":"progress","tooltip":"Checking project - 1040/1891 (54%)"}
[9/12/2024, 11:52:50 AM] [status-bar] notification:' {"progress":{"done":1060,"total":1891,"percentage":56},"opId":76,"type":"progress","tooltip":"Checking project - 1060/1891 (56%)"}
[9/12/2024, 11:52:54 AM] [status-bar] notification:' {"progress":{"done":1080,"total":1891,"percentage":57},"opId":76,"type":"progress","tooltip":"Checking project - 1080/1891 (57%)"}
[9/12/2024, 11:52:55 AM] [status-bar] notification:' {"progress":{"done":1140,"total":1891,"percentage":60},"opId":76,"type":"progress","tooltip":"Checking project - 1140/1891 (60%)"}
[9/12/2024, 11:53:00 AM] [status-bar] notification:' {"progress":{"done":1160,"total":1891,"percentage":61},"opId":76,"type":"progress","tooltip":"Checking project - 1160/1891 (61%)"}
[9/12/2024, 11:53:04 AM] [status-bar] notification:' {"progress":{"done":1180,"total":1891,"percentage":62},"opId":76,"type":"progress","tooltip":"Checking project - 1180/1891 (62%)"}
[9/12/2024, 11:53:05 AM] [status-bar] notification:' {"progress":{"done":1200,"total":1891,"percentage":63},"opId":76,"type":"progress","tooltip":"Checking project - 1200/1891 (63%)"}
[9/12/2024, 11:53:07 AM] [status-bar] notification:' {"progress":{"done":1220,"total":1891,"percentage":64},"opId":76,"type":"progress","tooltip":"Checking project - 1220/1891 (64%)"}
[9/12/2024, 11:53:13 AM] [status-bar] notification:' {"progress":{"done":1240,"total":1891,"percentage":65},"opId":76,"type":"progress","tooltip":"Checking project - 1240/1891 (65%)"}
[9/12/2024, 11:53:17 AM] [status-bar] notification:' {"progress":{"done":1260,"total":1891,"percentage":66},"opId":76,"type":"progress","tooltip":"Checking project - 1260/1891 (66%)"}
[9/12/2024, 11:53:18 AM] [status-bar] notification:' {"progress":{"done":1280,"total":1891,"percentage":67},"opId":76,"type":"progress","tooltip":"Checking project - 1280/1891 (67%)"}
[9/12/2024, 11:53:22 AM] [status-bar] notification:' {"progress":{"done":1300,"total":1891,"percentage":68},"opId":76,"type":"progress","tooltip":"Checking project - 1300/1891 (68%)"}
[9/12/2024, 11:53:22 AM] [status-bar] notification:' {"progress":{"done":1320,"total":1891,"percentage":69},"opId":76,"type":"progress","tooltip":"Checking project - 1320/1891 (69%)"}
[9/12/2024, 11:53:22 AM] [status-bar] notification:' {"progress":{"done":1340,"total":1891,"percentage":70},"opId":76,"type":"progress","tooltip":"Checking project - 1340/1891 (70%)"}
[9/12/2024, 11:53:22 AM] [status-bar] notification:' {"progress":{"done":1360,"total":1891,"percentage":71},"opId":76,"type":"progress","tooltip":"Checking project - 1360/1891 (71%)"}
[9/12/2024, 11:53:25 AM] [status-bar] notification:' {"progress":{"done":1400,"total":1891,"percentage":74},"opId":76,"type":"progress","tooltip":"Checking project - 1400/1891 (74%)"}
[9/12/2024, 11:53:26 AM] [status-bar] notification:' {"progress":{"done":1480,"total":1891,"percentage":78},"opId":76,"type":"progress","tooltip":"Checking project - 1480/1891 (78%)"}
[9/12/2024, 11:53:26 AM] [status-bar] notification:' {"progress":{"done":1520,"total":1891,"percentage":80},"opId":76,"type":"progress","tooltip":"Checking project - 1520/1891 (80%)"}
[9/12/2024, 11:53:27 AM] [status-bar] notification:' {"progress":{"done":1620,"total":1891,"percentage":85},"opId":76,"type":"progress","tooltip":"Checking project - 1620/1891 (85%)"}
[9/12/2024, 11:53:28 AM] [status-bar] notification:' {"progress":{"done":1660,"total":1891,"percentage":87},"opId":76,"type":"progress","tooltip":"Checking project - 1660/1891 (87%)"}
[9/12/2024, 11:53:29 AM] [status-bar] notification:' {"progress":{"done":1700,"total":1891,"percentage":89},"opId":76,"type":"progress","tooltip":"Checking project - 1700/1891 (89%)"}
[9/12/2024, 11:53:29 AM] [status-bar] notification:' {"progress":{"done":1711,"total":1891,"percentage":90},"opId":76,"type":"progress","tooltip":"Checking project - 1711/1891 (90%)"}
[9/12/2024, 11:53:31 AM] [status-bar] notification:' {"progress":{"done":1731,"total":1891,"percentage":91},"opId":76,"type":"progress","tooltip":"Checking project - 1731/1891 (91%)"}
[9/12/2024, 11:53:31 AM] [status-bar] notification:' {"progress":{"done":1751,"total":1891,"percentage":92},"opId":76,"type":"progress","tooltip":"Checking project - 1751/1891 (92%)"}
[9/12/2024, 11:53:33 AM] [status-bar] notification:' {"progress":{"done":1771,"total":1891,"percentage":93},"opId":76,"type":"progress","tooltip":"Checking project - 1771/1891 (93%)"}
[9/12/2024, 11:53:34 AM] [status-bar] notification:' {"progress":{"done":1791,"total":1891,"percentage":94},"opId":76,"type":"progress","tooltip":"Checking project - 1791/1891 (94%)"}
[9/12/2024, 11:53:35 AM] [status-bar] notification:' {"progress":{"done":1811,"total":1891,"percentage":95},"opId":76,"type":"progress","tooltip":"Checking project - 1811/1891 (95%)"}
[9/12/2024, 11:53:37 AM] [status-bar] notification:' {"progress":{"done":1831,"total":1891,"percentage":96},"opId":76,"type":"progress","tooltip":"Checking project - 1831/1891 (96%)"}
[9/12/2024, 11:53:38 AM] [status-bar] notification:' {"progress":{"done":1851,"total":1891,"percentage":97},"opId":76,"type":"progress","tooltip":"Checking project - 1851/1891 (97%)"}
[9/12/2024, 11:53:40 AM] [status-bar] notification:' {"progress":{"done":1871,"total":1891,"percentage":98},"opId":76,"type":"progress","tooltip":"Checking project - 1871/1891 (98%)"}
[9/12/2024, 11:54:02 AM] [status-bar] notification:' {"progress":{"done":1891,"total":1891,"percentage":100},"opId":76,"type":"progress","tooltip":"Checking project - 1891/1891 (100%)"}
[9/12/2024, 11:54:08 AM] [check:77] PHPStan process exited succesfully
[9/12/2024, 11:54:08 AM] [status-bar] notification:' {"opId":76,"result":"Success","type":"done"}
[9/12/2024, 11:54:08 AM] [status-bar] Hiding status bar, last operation result = Success
[9/12/2024, 11:54:08 AM] [check:77] Check completed for project, errors= {"fileSpecificErrors":{"file:///home/blah/blah/blah/subscriptions.php":["Dumped type: mixed"]},"notFileSpecificErrors":[]}

process list
ps aux |grep sander
blah   12222 10.1  6.0<PHONE_NUMBER>48 pts/1   S+   11:52   0:03 php /home/blah/blah/vendor/bin/phpstan analyse -c /home/blah/blah/phpstan.neon --error-format=json --no-interaction --memory-limit=1G -a /home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php -c /home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon
blah   13777  0.0  0.0   2620   460 pts/1    S+   11:52   0:00 sh -c '/usr/bin/php8.3' -c '/etc/php/8.3/cli/php.ini' '/home/blah/blah/vendor/bin/phpstan' 'worker' --configuration '/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon' --autoload-file='/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php' --memory-limit='1G' --port 33995 --identifier drm4nu3gl2 --
blah   13779 76.9  3.6<PHONE_NUMBER>64 pts/1   R+   11:52   0:26 /usr/bin/php8.3 -c /etc/php/8.3/cli/php.ini /home/blah/blah/vendor/bin/phpstan worker --configuration /home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon --autoload-file=/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php --memory-limit=1G --port 33995 --identifier drm4nu3gl2 --
blah   13780  0.0  0.0   2620   520 pts/1    S+   11:52   0:00 sh -c '/usr/bin/php8.3' -c '/etc/php/8.3/cli/php.ini' '/home/blah/blah/vendor/bin/phpstan' 'worker' --configuration '/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon' --autoload-file='/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php' --memory-limit='1G' --port 33995 --identifier pbcw5vb62a --
blah   13781  0.0  0.0   2620   520 pts/1    S+   11:52   0:00 sh -c '/usr/bin/php8.3' -c '/etc/php/8.3/cli/php.ini' '/home/blah/blah/vendor/bin/phpstan' 'worker' --configuration '/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon' --autoload-file='/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php' --memory-limit='1G' --port 33995 --identifier ai0hapoinb --
blah   13782 73.9  4.2<PHONE_NUMBER>12 pts/1   R+   11:52   0:25 /usr/bin/php8.3 -c /etc/php/8.3/cli/php.ini /home/blah/blah/vendor/bin/phpstan worker --configuration /home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon --autoload-file=/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php --memory-limit=1G --port 33995 --identifier pbcw5vb62a --
blah   13784  0.0  0.0   2620   524 pts/1    S+   11:52   0:00 sh -c '/usr/bin/php8.3' -c '/etc/php/8.3/cli/php.ini' '/home/blah/blah/vendor/bin/phpstan' 'worker' --configuration '/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon' --autoload-file='/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php' --memory-limit='1G' --port 33995 --identifier 1mg0zjge6v --
blah   13785 70.9  4.4<PHONE_NUMBER>56 pts/1   R+   11:52   0:24 /usr/bin/php8.3 -c /etc/php/8.3/cli/php.ini /home/blah/blah/vendor/bin/phpstan worker --configuration /home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon --autoload-file=/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php --memory-limit=1G --port 33995 --identifier ai0hapoinb --
blah   13787 73.1  4.7<PHONE_NUMBER>40 pts/1   R+   11:52   0:24 /usr/bin/php8.3 -c /etc/php/8.3/cli/php.ini /home/blah/blah/vendor/bin/phpstan worker --configuration /home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon --autoload-file=/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php --memory-limit=1G --port 33995 --identifier 1mg0zjge6v --
blah   13788  0.0  0.0   2620   524 pts/1    S+   11:52   0:00 sh -c '/usr/bin/php8.3' -c '/etc/php/8.3/cli/php.ini' '/home/blah/blah/vendor/bin/phpstan' 'worker' --configuration '/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon' --autoload-file='/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php' --memory-limit='1G' --port 33995 --identifier 97fhtt5ta3 --
blah   13794 74.0  3.8<PHONE_NUMBER>68 pts/1   D+   11:52   0:25 /usr/bin/php8.3 -c /etc/php/8.3/cli/php.ini /home/blah/blah/vendor/bin/phpstan worker --configuration /home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon --autoload-file=/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php --memory-limit=1G --port 33995 --identifier 97fhtt5ta3 --
blah   13795  0.0  0.0   2620   524 pts/1    S+   11:52   0:00 sh -c '/usr/bin/php8.3' -c '/etc/php/8.3/cli/php.ini' '/home/blah/blah/vendor/bin/phpstan' 'worker' --configuration '/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon' --autoload-file='/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php' --memory-limit='1G' --port 33995 --identifier q1b1ckngm9 --
blah   13796  0.0  0.0   2620   456 pts/1    S+   11:52   0:00 sh -c '/usr/bin/php8.3' -c '/etc/php/8.3/cli/php.ini' '/home/blah/blah/vendor/bin/phpstan' 'worker' --configuration '/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon' --autoload-file='/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php' --memory-limit='1G' --port 33995 --identifier 9e4w9v3gv7 --
blah   13797 74.1  4.3<PHONE_NUMBER>72 pts/1   R+   11:52   0:25 /usr/bin/php8.3 -c /etc/php/8.3/cli/php.ini /home/blah/blah/vendor/bin/phpstan worker --configuration /home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon --autoload-file=/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php --memory-limit=1G --port 33995 --identifier q1b1ckngm9 --
blah   13798 70.6  3.7<PHONE_NUMBER>96 pts/1   R+   11:52   0:24 /usr/bin/php8.3 -c /etc/php/8.3/cli/php.ini /home/blah/blah/vendor/bin/phpstan worker --configuration /home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon --autoload-file=/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php --memory-limit=1G --port 33995 --identifier 9e4w9v3gv7 --
blah   13799  0.0  0.0   2620   520 pts/1    S+   11:52   0:00 sh -c '/usr/bin/php8.3' -c '/etc/php/8.3/cli/php.ini' '/home/blah/blah/vendor/bin/phpstan' 'worker' --configuration '/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon' --autoload-file='/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php' --memory-limit='1G' --port 33995 --identifier 5h359vw71r --
blah   13801 70.3  4.4<PHONE_NUMBER>92 pts/1   R+   11:52   0:23 /usr/bin/php8.3 -c /etc/php/8.3/cli/php.ini /home/blah/blah/vendor/bin/phpstan worker --configuration /home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon --autoload-file=/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php --memory-limit=1G --port 33995 --identifier 5h359vw71r --
blah   13802  0.0  0.0   2620   456 pts/1    S+   11:52   0:00 sh -c '/usr/bin/php8.3' -c '/etc/php/8.3/cli/php.ini' '/home/blah/blah/vendor/bin/phpstan' 'worker' --configuration '/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon' --autoload-file='/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php' --memory-limit='1G' --port 33995 --identifier ke8684jufg --
blah   13804 81.5  4.1<PHONE_NUMBER>12 pts/1   R+   11:52   0:27 /usr/bin/php8.3 -c /etc/php/8.3/cli/php.ini /home/blah/blah/vendor/bin/phpstan worker --configuration /home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon --autoload-file=/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php --memory-limit=1G --port 33995 --identifier ke8684jufg --
blah   13805  0.0  0.0   2620   520 pts/1    S+   11:52   0:00 sh -c '/usr/bin/php8.3' -c '/etc/php/8.3/cli/php.ini' '/home/blah/blah/vendor/bin/phpstan' 'worker' --configuration '/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon' --autoload-file='/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php' --memory-limit='1G' --port 33995 --identifier op0xrthtuy --
blah   13806  0.0  0.0   2620   456 pts/1    S+   11:52   0:00 sh -c '/usr/bin/php8.3' -c '/etc/php/8.3/cli/php.ini' '/home/blah/blah/vendor/bin/phpstan' 'worker' --configuration '/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon' --autoload-file='/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php' --memory-limit='1G' --port 33995 --identifier up2varrnrg --
blah   13807 68.4  4.3<PHONE_NUMBER>28 pts/1   R+   11:52   0:23 /usr/bin/php8.3 -c /etc/php/8.3/cli/php.ini /home/blah/blah/vendor/bin/phpstan worker --configuration /home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon --autoload-file=/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php --memory-limit=1G --port 33995 --identifier op0xrthtuy --
blah   13809  0.0  0.0   2620   524 pts/1    S+   11:52   0:00 sh -c '/usr/bin/php8.3' -c '/etc/php/8.3/cli/php.ini' '/home/blah/blah/vendor/bin/phpstan' 'worker' --configuration '/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon' --autoload-file='/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php' --memory-limit='1G' --port 33995 --identifier 7ooh4dyyx4 --
blah   13811 72.4  3.7<PHONE_NUMBER>72 pts/1   R+   11:52   0:24 /usr/bin/php8.3 -c /etc/php/8.3/cli/php.ini /home/blah/blah/vendor/bin/phpstan worker --configuration /home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon --autoload-file=/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php --memory-limit=1G --port 33995 --identifier up2varrnrg --
blah   13812 72.5  3.8<PHONE_NUMBER>40 pts/1   R+   11:52   0:24 /usr/bin/php8.3 -c /etc/php/8.3/cli/php.ini /home/blah/blah/vendor/bin/phpstan worker --configuration /home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/config.neon --autoload-file=/home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/_config/4f09c5c6606a8ac1b953d798f98a5522/autoload.php --memory-limit=1G --port 33995 --identifier 7ooh4dyyx4 --
blah   76150  5.6  1.1 1088552 79800 pts/1   Sl+  09:18   8:47 /home/blah/.vscode-server/bin/4849ca9bdf9666755eb463db297b69e5385090e3/node /home/blah/.vscode-server/extensions/sanderronde.phpstan-vscode-3.2.7/out/server.js --node-ipc --clientProcessId=76112

Parallel analysis #
PHPStan now runs in multiple processes by default. The list of files to analyse is divided into small chunks which get processed by the same number of processes as the number of CPU cores you have. It works on all operating systems and doesn’t require any special PHP extension. And it’s enabled by default.

What if it's just phpstan launching all those process by itself, and there is no problem there 😅

I guess it could also depend if you have phpstan working with parellele processes, the only issue i believe is really the plugin no terminating the processes after certain actions, i guess a "hard" approach to pkill all ongoing processes before spawning new ones could be an ideia, probably a aggro approach :p

i guess a "hard" approach to pkill all ongoing processes before spawning new ones could be an ideia, probably a aggro approach

I wouldn't say that is aggro at all. Honestly I don't think there is ever an instance where I would want more than one process at any time. I would love for the feature to use multiple config files (not order of precedence), then it would make sense for multiple processes. (phpstan1.neon processes example/src/model, example/src/entity directories, phpstan2.neon then could do another set of directories with different scan rules defined in the neon config processing like example/test/unit example/test/integration etc.
The way it works right now it will always be scanning the same files regardless, perhaps a better approach would be to have a phpstan.maxProcesses vscode setting definition.
Alternatively only allow one scanner if using a phpstan cache, and just nuke it when we need to spin up a new one since it shouldn't take that much longer anyway. We probably don't even care about its results either since we will get more accurate results from the latest scanner.
If running without a cache, perhaps prompt the user if they want to terminate the run and start a new one as you could very well be editing files that phpstan has already scanned, and thus won't identify any new problems within related files if there are any yet to be scanned very likely in runs of large monoliths without a cache.

Parallel analysis #

Ah yeah I kind of assumed that you already knew that that was happening and that the 27 processes were a multiple of the max you'd set (like 3 instances of 9). It's definitely expected for there to be multiple processes, PHPStan does that when you run it from the commandline as well.

I guess it could also depend if you have phpstan working with parellele processes, the only issue i believe is really the plugin no terminating the processes after certain actions.

Exactly, how many processes PHPStan spawns is entirely up to you and is all configurable in the phpstan.neon file. What's up to the extension is ensuring that when you start another check, the existing check isn't also running alongside it.

i guess a "hard" approach to pkill all ongoing processes before spawning new ones could be an ideia, probably a aggro approach :p

Yeah that's close to the approach I'm using now. Now I just store the PIDs and the PIDs of the children and kill those. Using pkill is quite dangerous since I don't know whether there's other similar processes running that shouldn't be killed. For example:

You're also running PHPStan on the commandline
You have multiple VSCode windows open
You've got a shared dev server where multiple people are logged in under the same user and both are working on something using PHPStan.

Honestly I don't think there is ever an instance where I would want more than one process at any time.

You are able to limit the max number of processes in the PHPStan config file quite easily then. Note that all this extension does is call PHPStan like you normally would on the commandline, except it displays the errors nicely and watches for changes. Any configuration as to how many parallel processes you want to run etc should be done in PHPStan's configuration itself, the extension has no control over this.

I would love for the feature to use multiple config files (not order of precedence), then it would make sense for multiple processes. (phpstan1.neon processes example/src/model, example/src/entity directories, phpstan2.neon then could do another set of directories with different scan rules defined in the neon config processing like example/test/unit example/test/integration etc.

(I don't fully understand what you mean so I might be making some wrong assumptions about what you mean, please correct me if I do). Hmm I think what you mean is that you don't want multiple processes, but you do want multiple processes to be able to scan at the same time if those different scans some pre-defined different parts of the code base right? So it's fine for there to be 2 processes as long as one of them is targeting test/ and the other is targeting src/. Or maybe your point is more so that it'd be nice to have different rule sets targeting different parts of the codebase.
I'd recommend opening an issue in the PHPStan repo. This is something that PHPstan itself could/should support and not something this extension can control. Having different rulesets for different parts of the codebase does sound kind of handy (ESLint for example already does support this) and it may already be supported or might be a good feature suggestion. But in any case it's not something for this extension to implement.

The way it works right now it will always be scanning the same files regardless, perhaps a better approach would be to have a phpstan.maxProcesses vscode setting definition.

There's already a config setting for this in the PHPStan config (the one linked above), I think it's much better to use that instead since it then also works when using PHPStan on the commandline.

Alternatively only allow one scanner if using a phpstan cache, and just nuke it when we need to spin up a new one since it shouldn't take that much longer anyway. We probably don't even care about its results either since we will get more accurate results from the latest scanner.

If running without a cache, perhaps prompt the user if they want to terminate the run and start a new one as you could very well be editing files that phpstan has already scanned, and thus won't identify any new problems within related files if there are any yet to be scanned very likely in runs of large monoliths without a cache.

This is a tough one for a few reasons:

There's no way for this extension to know before queueing a new PHPStan scan whether the cache is going to be available or not. Again, PHPStan itself does know this, but the extension (which basically just calls ./vendor/bin/phpstan on the commandline) can not.
If it would know, there's no way to know to what degree there is a cache available. Let's say half of the files have been cached, would you call that cached or not.
There's no way to know before starting a check how much of the existing cache will be invalidated by the changed. A change to BaseClassForEverything.php will take a massive amount of time since it will invalidate the cache. But a change to NewFile.php might only invalidate a single file (itself). How do you differentiate between these two.

I'd again recommend opening an issue in the PHPStan repo itself, maybe the author of PHPStan is able to help you out here. You could consider getting PHPStan Pro, which does file watching as well (like this extension) except it does run from within PHPStan so it does have access to all the needed information (how much of the cache is present, how much will be invalidated, etc). Then you could ask the author of PHPStan (and thus PHPStan Pro) to add support for this.

I'll be closing the issue as fixed now, I think there have been three to-be-fixed issues in this thread:

Scan A is started, then scan B is started and scan A is not terminated, leading to two scans running side-by-side. That appears to have been fixed by martijn-dd. (described by him as "processes piling up", which makes sense)
Same issue as above, except the scan runs inside of Docker and is less easy to kill. I did not get confirmation that this was fixed by anyone, but neither did I get any reports that it's still broken and I did verify myself that it was fixed.
Multiple scans happening in parallel. Which is simply PHPStan using multiple workers for parallel processing. This is not an issue with the extension and is just something you should be able to configure yourself in your phpstan.neon.

If anybody has issues that do not fall within the above three categories (or falls into the first two but isn't fixed), feel free to re-open the issue. But I think the issue has been fixed then.

I'm happy with the explanation, but just to clarify a few points:

I think what you mean is that you don't want multiple processes, but you do want multiple processes to be able to scan at the same time if those different scans some pre-defined different parts of the code base right? So it's fine for there to be 2 processes as long as one of them is targeting test/ and the other is targeting src/.

Correct!
This could be integrated into the extension to just point different config files for different directories, then the extension can call phpstan with the correct config file based on the file that vscode reports was edited.

Honestly I don't think there is ever an instance where I would want more than one process at any time.

By this I didn't explicitly mean processes directly, but runners that this extension spins up. If PHPStan creates 7 processes, then I save a file, all 7 of those should be erased and a fresh 7 should spin up. If I were to word it better:
~ Honestly I don't think there is ever an instance where I would want more than one extension runner at any time. (except if we were to support scanning different directories)

I'd recommend opening an issue in the PHPStan repo. This is something that PHPstan itself could/should support and not something this extension can control. Having different rulesets for different parts of the codebase does sound kind of handy (ESLint for example already does support this) and it may already be supported or might be a good feature suggestion. But in any case it's not something for this extension to implement.

PHPStan does already support this via the parameters.paths config. If you were wanting to scan multiple paths / config files at the same time I could just call PHPStan multiple times.
phpstan analyse path/to/directory --configuration path/to/phpstan.neon & phpstan analyse path/to/another/directory --configuration path/to/another/phpstan.neon &

This is possible in the CLI of course, but not via this extension (I would have to awkwardly change the "phpstan.configFile" every time I switch between working on src/ vs test/ in my example. and this is exactly what I do, it is quite frustrating

Correct!
This could be integrated into the extension to just point different config files for different directories, then the extension can call phpstan with the correct config file based on the file that vscode reports was edited.

Ah yeah that's a fair point. While this would be possible, I do still think it would be better for this to be solved upstream for a few reasons:

It's relatively hard to know under what config file a certain file falls. PHPStan has some non-trivial rules for determining whether a given file is or is not part of a project. I did recently come up with a hack for extracting this data, but it's only available in PHPStan 1.12+ and it only works in a pull-fashion (I need to periodically call the PHPStan binary and ask it which files it would include), which would mean that something trivial like you creating a new file in a directory and wanting it to be scanned does not work. Something like this is much easier to do within the same PHPStan project.
This could potentially become confusing when a given file falls under multiple configs
Let's say that src/ and test/ both import from base/, then base/ will be checked twice
PHPStan invalidates the cache when it is called with a different config file. Unless you are so smart as to set a different tmpDir for every config file (which I'm sure you are but I'm also quite a lot of people will forget) this means that almost every scan will be uncached.
It would be nicer for such a feature to be available on the commandline, and for it to be available to everyone :)

By this I didn't explicitly mean processes directly, but runners that this extension spins up. If PHPStan creates 7 processes, then I save a file, all 7 of those should be erased and a fresh 7 should spin up. If I were to word it better:

~ Honestly I don't think there is ever an instance where I would want more than one extension runner at any time. (except if we were to support scanning different directories)

Ah yeah sorry I misunderstood then. Then we indeed agree that there should always only be one scan running (even if such a scan contains multiple workers). Only the latest scan should be running, the rest should be killed.

PHPStan does already support this via the parameters.paths config. If you were wanting to scan multiple paths / config files at the same time I could just call PHPStan multiple times.

It indeed does sort of support this, but not fully. What I'd see as an ideal implementation is the way ESLint did it, where you are able to determine which rules to apply on a per-file basis. This would solve your issue of needing to switch configs (since you'd only need one config), ensure the extension works perfectly with this as well, while also making it so you'd only need to call PHPStan once on the commandline. Since PHPStan has very much so been created with the idea of "only one config file" (in contrast to for example TypeScript), which the cache being cleared when a different config file is used is one example of, I think an ideal solution is one that keeps it all in one config.

PHPStan invalidates the cache when it is called with a different config file. Unless you are so smart as to set a different tmpDir for every config file (which I'm sure you are but I'm also quite a lot of people will forget) this means that almost every scan will be uncached.

This is indeed how mine is set up. So in theory there should be no crosstalk between cache's (and I have never personally experienced such, my cache is never invalidated and I have yet to have a false report due to this cache setup)

It's relatively hard to know under what config file a certain file falls

I'm not sure if we need to know. We already include settings like phpstan.paths
"phpstan.paths": {
    "${workspaceFolder}": "/var/www/example",
},

Path mapping for scanned files. Allows for rewriting paths for for example SSH or Docker.

Aware this topic has diverged a bit, it may be better to discuss this on a more topical issue. But I think it would be a great feature to have something similar to this, but instead of specifying a path mapping for SSH or Docker, we specify which config file to use
"phpstan.configPaths": {
    "${workspaceFolder}/src/*": "${workspaceFolder}/src.phpstan.neon",
    "${workspaceFolder}/test/*": "${workspaceFolder}/test.phpstan.neon",
},

In this example, we only need to check if the file I just saved in vscode matches the glob result of ${workspaceFolder}/src/* or ${workspaceFolder}/test/* and call PHPStan with the correct config accordingly. Perhaps a warning on this setting to ensure you have different tmpDir for your cache's if they have a chance of every having any related files if you believe most people don't configure this already.
I know this is sounding more like a feature request, so it may be better for me to initiate one if you are open to the idea?

Oh there never is crosstalk between caches since PHPStan deletes the cache when you use a different config file from last time. On one hand that's a good thing, on the other hand this makes it so that every time you switch your cache is deleted and you have to do a full uncached scan.

This is not necessarily true if the config files have different parameters.tmpDir defined, which they should do if you are using multiple config files within the same project that have different path requirements.

It could lead to some hard-to-understand cases. If again both src/ and test/ include base/, a change in base/ will now either cause both to be checked if you've configured it as such (which again hammers the CPU) or will cause neither to be checked, potentially leading to stale errors.

I'd say that's down to the individual dev to ensure that this can't happen, or if it does, that it is not too taxing on their machine. You would need to run both anyway (and probably will, like I do) for valid static analysis (potentially we could just queue one config after another? Doing the process slower is better than not being able to do it at all)
I've created a new issue for this separate topic: https://github.com/SanderRonde/phpstan-vscode/issues/107

First big up for this extension.
I'm using phpstan from terminal too but having the warnings in VSC is very nice.
I'm just pointing out the last comment from @Sectimus because it could lead to a solution (if I'm correctly understanding the global pattern).
Queing the scan requests instead of parallel triggering to control the flow of phpstan process. For me I don't need phpstan to be realtime, cause I know that the current files I'm working on are possibly not clean. But at the end of a work session I launch all the code mess detector. Could be every 10 minutes or so if files had been touched and saved.
Could be some sort of option on save or delayed.

Could be some sort of option on save or delayed.

@quazardous This could still cause issues if the delayed run gets triggered after 10 minutes and you edit a file it has scanned already (but not yet completed analysis).

Could be some sort of option on save or delayed.

@quazardous This could still cause issues if the delayed run gets triggered after 10 minutes and you are still working to edit a file it has scanned already (but not yet fully completed the analysis).

Yes it could there will always be caveat. But only one scan at a time it maybe won't lead to crash freeze...

Yes it could there will always be caveat. But only one scan at a time it maybe won't lead to crash freeze...

A pro tip if you want to use the CLI and still get VSCode integration is to just run the same command that the extension runs
go to the output tab and click the dropdown on the right to change the context to PHPStan to see what command it runs, yours needs to be identical
Make sure you have a cache defined in your config. Now when the extension runs, it should give you results in your IDE and complete instantly.

@Sectimus I was using a dockerized phpstan before official docker support so terminal and vscode use the same config/stuff. I could use inotify or some sort of daemon but if the extension already listen to update events why bother 😁 I'm waiting I'm sure it will work fine in the end. The complete freeze is not happening anymore it's great 👍. And I have a kill all script in case of emergency...

Hmm I think running the checker in the background might be a bit too complex to implement and understand. However I do think I've got a fairly decent solution for you. If you simply set the max number of processes to 1 and limit its resources in the phpstan config, you can then disable automatic checking on file change in the extension
settings (phpstan.enabled -> false) and use the PHPStan: Scan project for errors command to queue a scan. This command might take a long time (or not, depending on cache) but it'll:

Take up few resources due to the 1-process limit
Show you its progress
Show you errors once it completes

Queueing checks instead of running them in parallel isn't necessarily something the extension can do, but you have quite a bit of control over this through the parallel section of the PHPStan config file. If a full check is constantly leading to system freezes you can limit the resources you assign to PHPStan through the config file, then checks will take longer but not cause a freeze (which you mentioned you'd rather have).


Add tests

Related to #15
It's a bit of a pain in the neck to work on the plugin and have to test all the cases manually.
Some unit or integration tests will help a lot.
I don't have time for this at the moment. So just leaving here in case we can get a champion to contribute 🙂

Another option is Jest which brings code coverage out of the box.

Damn! I thought I drop a message here yesterday. It seems like it didn't send.
I also vote for Jest. Batteries included and more performant.


#2808 Sorting numerical or Integer tags in ascending order in AEM

Addresses #2808
The PR adds a "Numbers First" checkbox to the Sort Nodes tool

If checked then numbers will be sorted first followed by alphabetical values.

LGTM! I will update changelog for you! Thanks @YegorKozlov


Add tests to ensure that the converted datasets actually work

Why: we want to ensure that if a user downloads either the Loom or Seurat file that they are able to actually use and read the file.
Definition of Done: Using a test fixture H5AD file, call the conversion function from the upload mechanism. Assert that all required fields are accessible by loompy and Seurat respectively for the .loom and .rds files.
Note: this will require some research to figure out how to read the .rds file.

Dup of #939, closing


Virtual Refs not possible to pass aditional configurations

Information

Version: 5.13.0
Type: Issue

Description
I would like to pass aditional configurations to virtual refs, such as "justOne" and "localField", this isn't possible right now but is very easy doable.
Example
In my case, I have a class which contains a field "account_id", which is the reference to the other Model. Also, I have a field called "account" which is my virtual reference, the thing is, I don't always need to populate that field but I always want the referenced id and in my case, my "account" field should be just an object when populated, not an array, and this is possible by passing an option "justOne: true" to the virtual reference configuration.
Below is my class that contains my virtual reference:
export class IAccountData {
    public _id?: ObjectId;

    @Required()
    public type?: String;

    @Required()
    public key?: String;

    @Required()
    @Default({})
    public value?: Object;

    @Ref(IAccount)
    @Required()
    public account_id?: Ref<IAccount>;

    @VirtualRef('Account', '_id')
    @PropertyName('account_id')
    public account?: VirtualRef<IAccount>;
}

You can see that I have to set the @PropertyName('account_id') to make it work, since it's the only way I found to override the "localField" property. But I can't set the "justOne" property which is more important.
To fix that, we can just do something like:
(virtualRef.ts)
export function VirtualRef(type: string, foreignField: string, justOne: Boolean = false) {
  return PropertyRegistry.decorate((propertyMetadata: PropertyMetadata) => {
    propertyMetadata.store.merge(MONGOOSE_SCHEMA, {
      ref: type,
      localField: propertyMetadata.name,
      foreignField,
      justOne
    });
  });
}

Or instead of passing more parameters, accept just one parameter of type Object which will contain all the configurations

Hello @ghmendonca,
I prefer object configuration ;) but to not broke exiting implementation, we have to support twice signature. One with type and second one with object.
The feature is added to the backlog ;)

Expected:
export interface IVirtualRefOptions { // Maybe mongoose has an interface defined for VirtualRef
  type: string;
  foreignField: string;
  justOne:  boolean;
}
export function VirtualRef(type: string | IVirtualRefOptions) {
}

I agree, both signatures can work. I will search if mongoose has an interface and I will push a PR.
Thanks!


TypeScript 2.9

Coverage remained the same at 100.0% when pulling 80b647092cb1662b636a4fa128553ef8625f5319 on feature/typescript-2.9 into 6906f73cc40cf1a6b05936f77bdce8592e9801fd on master.


CO/CH transposed in wsg_species_presence?

Changes at https://github.com/smnorris/bcfishpass/commit/ea6645c32ca58f9a7294e899beec6934e4b3e0a3 explain how issue https://github.com/smnorris/bcfishpass/issues/332 arose and why the file currently indicates CO presence in UFRA, not CH (CH is correct).
Will need to check if this affects any CWF reporting. Unlikely that WCRP watersheds are affected but it seems likely some rail watersheds could be.

There are 47 watershed groups likely affected - where one of CH or CO is noted as present, but not both.
48 if including the already fixed VICT.
Of those, 11 (plus VICT) were part of the rail reporting:
watershed_group_code | ch | co | rail
----------------------+----+----+------
 BLAR                 |    | t  |
 CHES                 |    | t  |
 CHIL                 |    | t  |
 EUCH                 |    | t  |
 EUCL                 |    | t  |
 FRAN                 |    | t  | rail
 GLAR                 |    | t  |
 HERR                 |    | t  |
 HOLB                 | t  |    |
 JENR                 |    | t  |
 KEEC                 | t  |    |
 KINR                 | t  |    |
 KUMR                 | t  |    |
 LCHR                 |    | t  |
 LRDO                 | t  |    |
 LSAL                 |    | t  | rail
 LTRE                 |    | t  | rail
 MAHD                 |    | t  |
 MBNK                 | t  |    |
 MCGR                 |    | t  |
 MESC                 |    | t  |
 MFRA                 |    | t  |
 MORI                 | t  |    |
 MORK                 |    | t  | rail
 NAHR                 |    | t  |
 NARC                 |    | t  | rail
 NASC                 | t  |    |
 NAZR                 |    | t  |
 NBNK                 | t  |    |
 NECL                 | t  |    |
 NEVI                 | t  |    |
 PORI                 | t  |    |
 SAJR                 | t  |    | rail
 SALR                 |    | t  | rail
 STUL                 |    | t  | rail
 STUR                 |    | t  |
 SWIR                 |    | t  |
 TABR                 |    | t  | rail
 TATR                 |    | t  |
 TESR                 |    | t  |
 TWAC                 |    | t  | rail
 UCHR                 |    | t  |
 UFRA                 |    | t  | rail
 UJER                 |    | t  |
 UNAR                 |    | t  |
 UNUR                 | t  |    |
 USKE                 |    | t  |

This affects a few things:

per species habitat reporting (obviously)
total habitat reporting is likely an overestimate relative to what we would expect with the corrected data:

CO gradient/discharge/channel width habitat thresholds are slightly more generous than CH
when reporting, CO rearing numbers are bumped up 1.5x in wetlands, CH are not

because observations for species identified as not being not present in a group are filtered on load, after this is fixed more observations will be present in the dataset, and additional natural barriers may have >4 observations upstream and thus be removed from model

Fix did not include USKE - it does not look like that one is incorrect, there are 30 CO observations vs 8 CH.

It looks to me like USKE should have both CH and CO

Fish Ranges (FISS_FISH_RANGES_SVW) notes both species as Core in that group
all maps and spreadsheets I have on file from scoping exercise indicate both CH and CO presence

Not sure how this one got changed, CH was null on initial load of the file to version control:
https://github.com/smnorris/bcfishpass/commit/882bfcec7a3d02c6057af3a7a566c249a66166f5#diff-afb1226231660c5462fc982007b80783150ce2bd1af61144c5a8b0caba304ac0R241


Issue when trying to login

Open Template Hub - Bug Report
Description
Define the problem clearly
I'm getting this error when i try to login.
{"error":{"code":400,"message":"CONFIGURATION_NOT_FOUND","errors":[{"message":"CONFIGURATION_NOT_FOUND","domain":"global","reason":"invalid"}]}}
Supplementary Info
Host = https:/replit.com / https://repl.it
https://mail.playpiglin.net
Open Template Hub © 2021

Hi @PiglinPlayz,
Which provider are you using? (Firebase?)
This issue seems to be related with the service provider.
There might be extra permission / configuration needed on your provider.
Could you please review below link?
https://www.reddit.com/r/Firebase/comments/fd19x5/whats_causing_firebase_code_400_message/
Regards,
Fatih


Rate limit exception got at a safeguarded seemingly single operation

I get a rate limit exception at
	from ./outside-collaborators-handler.rb:69:in `add_repo_collaborator'

Strange, there is a check_and_wait_until_reset just before that line..

Originally posted by @JeroenKnoops in https://github.com/icub-tech-iit/outside-collaborators/issues/78#issuecomment-933188356

Here's the line:
https://github.com/icub-tech-iit/outside-collaborators/blob/0f7fa4be91da0a66b84e5a571a0c1dbb14a4335d/scripts/outside-collaborators-handler.rb#L69

Hi @JeroenKnoops
This bug is a bit puzzling.
The documentation doesn't provide any useful clue as to if the operation shouldn't be considered single/atomic for any reason:

http://octokit.github.io/octokit.rb/Octokit/Client/Organizations.html#organization_member%3F-instance_method
https://docs.github.com/en/rest/reference/orgs#check-organization-membership-for-a-user

You may try to give the safeguard on the rate limit a bit of slack by relaxing the following condition
https://github.com/icub-tech-iit/outside-collaborators/blob/0f7fa4be91da0a66b84e5a571a0c1dbb14a4335d/scripts/helpers.rb#L8
into something like
if rate_limit.remaining >= 10 then

It's a mere workaround I know but it would help us inquire the problem a bit deeper.

Hi @JeroenKnoops
Did you get this error again while running your jobs?

I've changed the line in the helpers.rb to already wait when rate_limit is < or equal to two and that resolved it.

Fantastic!
I'll open up a PR then.


Not working on Ubuntu

Apologies for having to ask, but I really can't figure this one out. Please could you take a look at my problem as posted on superuser?
http://superuser.com/questions/1095023/syntastic-not-working-on-ubuntu
I'm not sure where to go next with debugging this, so any pointers on a "syntastic debug mode" or similar would be very helpful!

Right, I suppose this should be in the FAQ: to work with multiple versions of Python, install virtualenv, pyenv, or similar, activate the relevant environment, install the checkers you plan to use, set g:syntastic_python_checkers accordingly, and run Vim from the environment.
If this doesn't solve your problem then please explain what you did, what did you expect to happen, and what happened instead.  Post a minimal file that illustrates the problem, enable debugging, and post the logs.

Yes apologies for the link to SU. It seemed unnecessary to copy/paste that content in here..
I have a standard dotfiles setup - same config on OSX, Debian & now Ubuntu. Syntastic is not showing any errors in a broken Python file on Ubuntu. The same setup works on OSX/Debian.
Using test.py, which contains only a single line:
import json

:SyntasticInfo output is the same on OSX/Ubuntu/Debian:
Syntastic version: 3.7.0-157 (Vim 704, Linux)
Info for filetype: python
Global mode: active
Passive filetypes: java sass scss
Filetype python is active
The current file will be checked automatically
Available checkers: pyflakes python
Currently enabled checkers: pyflakes python

:SyntasticCheck does nothing, likewise :Errors.
I forcefully show errors by running :echo system('pyflakes test.py') in vim, which produces:
test.py:1: 'json' imported but unused

My syntastic .vimrc config is (from my dotfiles):
let g:syntastic_python_checkers = ['pyflakes', 'python']
let g:syntastic_python_pyflakes_exe = 'python3 -m pyflakes'
let g:syntastic_python_flake8_args='--ignore=E501'
let g:syntastic_mode_map = { 'mode': 'active',
					       \ 'active_filetypes': [],
					       \ 'passive_filetypes': ['java', 'sass', 'scss'] }

You mention "enable debugging" above - is that syntastic debugging? How can I enable that?

Yes apologies for the link to SU. It seemed unnecessary to copy/paste that content in here..

For one, GitHub doesn't index posts on SO...

let g:syntastic_python_pyflakes_exe = 'python3 -m pyflakes'

From my answer above:

Right, I suppose this should be in the FAQ: to work with multiple versions of Python, install virtualenv, pyenv, or similar, activate the relevant environment, install the checkers you plan to use, set g:syntastic_python_checkers accordingly, and run Vim from the environment.

Try this first.

I can show errors by running :echo system('pyflakes test.py') in vim, which produces:

This is not directly relevant, since you have exe = 'python3 -m pyflakes'.  So try :echo system('python3 -m pyflakes test.py') instead.

You mention "enable debugging" above - is that syntastic debugging? How can I enable that?

This is explained in the manual: :h syntastic-config-debug.
So, please try this:

upgrade syntastic to the latest master HEAD
install pyflakes in virtualenv and run Vim from the environment, as I said above
if you still have problems: open your test file, set g:syntastic_debug to 3, run :SyntasticCheck pyflakes, then run :mes and post the output.

Thanks for your comments. It came down to the g:syntastic_python_pyflakes_exe config - somehow my ubuntu box had pyflakes installed for python2, but not python3.. Your suggestion of running the following fixed things for me:
:echo system('python3 -m pyflakes test.py')

Thank you for sparing some time for this!


Fetch choices from an endpoint

Add a useEffect to the useChoiceBoardModel.ts that fetches the initial choices from an endpoint and set the initial options from that.
Tip: this endpoint could be the mock server endpoint

Hi ,Can you assigned me this?

HI @priya-pri ! 👋🏻
Welcome to stop analyzing!
Sure, I've just assigned the issue to you. If you need some assistance, please let me know.!
Thanks for your help! =)

HI @priya-pri ! 👋🏻
Welcome to stop analyzing!
Sure, I've just assigned the issue to you. If you need some assistance, please let me know.!
Thanks for your help! =)

Thanks @tiagostutz

HI @YASH3166
Sure, I've just assigned the issue to you. If you need some assistance, please let me know.!

Is this done? I would like to contribute

Is this done? I would like to contribute

Hi @mpirescarvalho ! 👋🏻
Are you still interested in tackling this issue?

Will you please assign this issue to me ?

Sure, just assigned! Go ahead.!
Thanks!

May I take on this one as well?

Sure @adam-p-git !
Go ahead. Just assigned to you.!

@tiagostutz Would it be okay if I rewrite fetching logic with the help of react-query and hooks? Also I have a suggestions to change /choice endpoint into /choices, I think that is more suitable.

Absolutely, go ahead. You can implement and we can discuss this, if needed, in the PR.
Awesome.!

Hey ,I would like to contribute in this issue

@tiagostutz  Hey, I would like to contribute in this issue, Please let me know if this needs to be done.

hey , I this is my first issue is open source i want to contribute in this , can you assign to me

Hey Can i help? I wanna contribute!


Skip system checks

Certain Django checks require a database connection, so these would fail
before the command is run. So skip these for wait_for_database command.

Background reading: Django documentation on requires_system_checks.

Aren't those checks meant to verify a correct Django setup? Shouldn't we assume that it's okay not to support deploying (or actively abort) a broken setup?

The system check framework does checks on the database backend by default.
These checks can (sometimes, depending on backend and django version) do database connection and queries test test out some feature....
Example again is mysql/mariadb on Django <2.1, it will throw an connection error in the feature check code...
But there could also be 3th party libraries that, for example, add some custom Field. Those usually also add checks, to make sure the database supports some native feature.
So these checks really should be done after this management command.
(e.g. explicitly call the 'check' command after this one)

Thanks Jorrit! :+1: