microsoft / microsoft/aspire

DCP hard kills child process after 6 seconds when debugger is paused at breakpoint

Open
#18,237 4 comments 0 reactions 0 assignees View on GitHub
area-orchestrator triage:bot-seen
Dominant language
C#
Stars
6.3k
Forks
991
Avg merge
2d 15h
Merged PRs (30d)
196

Description

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Describe the bug

This is the scenario that leads to the problem:

- Aspire version 13.1.0 running locally on a Windows 11 PC
- Visual Studio solution has multiple background worker processes, all registered with the Aspire AppHost. Worker processes correctly handle cancellation tokens and therefore handle the worker process (resource, as seen in the Aspire Dashboard) being shutdown/stopped.
- Aspire Host is being launched from a command window (not Visual Studio) via: `dotnet run` in the command window within the directory that contains the App Host.
- The Host launches. The Aspire Dashboard is accessible. The worker process starts doing work. All good so far.
- A breakpoint is set in the StopAsync method of one of the worker processes.
- Visual Studio "Debugger Attach to Process" is used, and the worker process listed in the list of worker processes is selected.
- The Visual Studio debugger is left running. All good so far - no problems or unexpected behaviour.
- Then I click the stop resource button in the Aspire Dashboard. The breakpoint in the "StopAsync" method is reached.
- If I **do not continue execution** within Visual Studio and simply stare at the breakpoint that has been reached, then exactly after 6 seconds the Visual Studio debug session ends and the worker process stops with exit code 1 (0x1).
- If I repeat the above but this time continue execution after the breakpoint is hit (and ensure no other breakpoints are hit) and do this within 6 seconds, then the worker process exits with exit code 0 (0x0).

I'm assuming that this "6 second kill" is purely a "paused too long at breakpoint" debugging inconvenience and hopefully not a production concern (i.e. hoping that there isn't an issue on production whereby the cleanup actions only have 6 seconds to complete).

I have read about something called the Developer Control Plane - I'm not sure if this is related to the "6 second kill".

Anyway, I'm raising this bug in the hope that it is a genuine bug that could be fixed in future.

### Expected Behavior

When a breakpoint is set in Visual Studio and the Aspire worker process (resource) is stopping then a developer has more than 6 seconds to trace through code to make sure the cleanup code does what it needs to do. At present, 6 seconds is not enough time for a developer to step through their code.

### Steps To Reproduce

_No response_

### Exceptions (if any)

_No response_

### Aspire doctor output

_No response_

### Anything else?

.NET 8,0
Aspire 13.1.0
Visual Studio 2022

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.