search

dotnet / aspire

Tools, templates, and packages to accelerate building observable, production-ready apps
https://learn.microsoft.com/dotnet/aspire
MIT License
3.86k stars 462 forks source link

DCP does not shut down, ephemeral Docker network not cleaned up after running tests from aspire-samples repository #6504

Open karolz-ms opened 2 weeks ago

karolz-ms commented 2 weeks ago

Is there an existing issue for this?

Describe the bug

(see title)

Expected Behavior

DCP should shut down and leave machine in clean state, including cleaning up the ephemeral Docker network.

Steps To Reproduce

  1. Make sure the machine has the following prerequisites
    • Dapr 1.14+ (installed and initialized)
    • Node LTS (20.x)
    • Python 3.10+
  2. Clone dotnet/aspire-samples repository
  3. Build the repository and run tests

Exceptions (if any)

No response

.NET Version info

9.0 RC

Anything else?

No response

zejji commented 2 weeks ago

I am seeing this issue when developing using Aspire in normal usage - see screenshot below. These networks need cleaning up manually.

Update: On further testing, it appears Aspire never clears up any networks it creates.

My platform details:

Image

davidfowl commented 1 week ago

Fixed in https://github.com/dotnet/aspire/pull/6560

joperezr commented 1 week ago

Reopening as there seem to still be some scenarios where this can be reproduced, particularly when using dotnet watch.

karolz-ms commented 1 week ago

The fixes included in #6560 addressed DCP internal problems.

The current version of dotnet watch kills entire process tree, including DCP, which thus does not have a chance to do the cleanup. This is a known issue that @tmat is fixing as part of the major dotnet watch renewal.

We also have the problem of DCP instances lingering during test run, which is mostly the Aspire test application builder issue, but also constrained by lack of ability to "tell" DCP to shut down before the process that launched DCP is terminated. This is tracked by https://github.com/dotnet/aspire/issues/6561

Once new `dotnet watch arrives and https://github.com/dotnet/aspire/issues/6561 is resolved, I do not expect any additional work to resolve the scenario described in this issue.