Since using the plugin, I am getting a lot of orphaned networks and failed `ddev start`s

[andrewbelcher]

Is there an existing issue for this?

• [X] I have searched the existing issues

Are you sure that this bug is related to this DDEV Integration Plugin?

• [ ] I am sure

Enter your error report ID (If available)

No response

Describe the bug

Since installing the plugin (which is super useful), I seem to be frequently encountering DDEV failing and leaving the project's network in place, resulting in me having to stop / docker network prune before I can resume.

Example error:

Error response from daemon: network ddev-<SITENAME>_default is ambiguous (3 matches found on name)' 

It is usually seen at a similar time to the intellij plugin showing errors in syncing ddev state.

Steps to reproduce

Having a DDEV project running and IDE open. At some point it happens...

Additional context

No response

[rfay]

The ambiguous network problem is hopefully fixed in DDEV HEAD, would you be willing to try that? https://ddev.readthedocs.io/en/latest/developers/building-contributing/#testing-latest-commits-on-head

We'll also have a DDEV pre-release and a release this week. This problem does seem to only happen to people using PhpStorm (or perhaps using this extension).

• https://github.com/ddev/ddev/issues/5193

/cc @stasadev

[chrhas79]

For me it happens, when i open another PHPStorm Instance with another ddev project, which is not started. I end up with "web" and in my case "opensearch" in a stopped status and 5 or 6 networks with the same name. I tested this with the newest ddev version.

Just some speculation here, but could it be that the Composer integration in PHPStorm is causing this issue? I think the Cli Interpreter is automatically set to ddev. If you start PHPStorm for a stopped ddev project, PHPStorm checks for new composer package updates, which causes the start of the ddev "web" container.

If you have PHP Mess Detection or PHP Codesniffer set up in PHPStorm in your projects and open a php file it starts the "web" container of the ddev project, too. But in this case only with one network.

If this is the intended behavior and if in any way possible, i would like to be able to disable this "automatic starting" in the plugin settings.

[stasadev]

@chrhas79 , thanks, you made a really good observation.

I tested it, and when you have no running projects and you open a DDEV project in PhpStorm, nothing starts.

And when you have one running DDEV project and open another stopped DDEV project in PhpStorm, it shows up as starting in ddev list and then becomes unhealthy after a while.

---

could it be that the Composer integration in PHPStorm is causing this issue? i would like to be able to disable this "automatic starting" in the plugin settings.

When I uncheck the checkbox PHP > Composer > Check for available package updates, it doesn't start. Unfortunately, this is not a global option and doesn't directly depend on the plugin.

---

I got the same results after disabling the DDEV Integration plugin (the configurations for the remote CLI interpeter remained intact). It sees that another web container (from another project) is running and thinks that this is the reason to start it here.

[stasadev]

@nico-loeber , if this plugin installs the PHP interpreter, can it also disable the composer check for updates?

Found this setting loadUpdateAvailability="false" in .idea/workspace.xml:

<component name="ComposerSettings" loadUpdateAvailability="false" synchronizationState="SYNCHRONIZE">
  <pharConfigPath>$PROJECT_DIR$/composer.json</pharConfigPath>
  <execution>
    <interpreter name="DDEV" composer="composer" />
  </execution>
</component>

[nico-loeber]

Hey @stasadev, that's probably possible, but I am not sure about the consequences. I would like to avoid disabling features that might be of use (Notifications on not installed composer packages / updates / other stuff).

The plugin is just doing the configuration work you would do manually when using ddev. So I think this is a more general problem with ddev / phpstorm that the container is started into an unhealthy state.

In case there is no other solution the ddev documentation can be extended to disable this feature when setting up ddev with phpstorm and then the plugin might adapt this as well. Some settings are quite complicated to implement while others are easy. Didn't find an API for that setting yet.

[stasadev]

@nico-loeber, I agree, that's really not what this plugin is supposed to do.

Also, as @chrhas79 mentioned, there are a lot of other things that can start the web container:

If you have PHP Mess Detection or PHP Codesniffer set up in PHPStorm in your projects and open a php file it starts the "web" container of the ddev project, too. But in this case only with one network.

The problem is that PhpStorm starts only the web container (where the remote interpreter is located), not all the services from .ddev/.ddev-docker-compose-full.yaml. On the other hand, when you run ddev start, it does many other things besides docker-compose up.

So the basic recommendation would be to always run ddev start before opening projects in PhpStorm 😅

[nico-loeber]

Yes, ddev start does a lot of things. This is one of the problems of the plugin. For example the plugin "api" to ddev failes when ddev needs to download a new docker compose version and stuff like that. Sadly ddev is not just docker compose configuration manager but has its own infrastructure. Not sure how we can solve this issue... let me know if you have any idea. Executing ddev start on project open might be an option some people might concider even a nice feature but you easily get into race coniditions as ddev won't start as fast as the process that will check the composer dependencies I think.