aspire icon indicating copy to clipboard operation
aspire copied to clipboard

VS Code Debug Aspire crashes after running with exit code 0

Open gabynevada opened this issue 1 year ago • 2 comments

Is there an existing issue for this?

  • [X] I have searched the existing issues

Describe the bug

When starting a debug session on aspire in VSCode, the AppHost runs completely, starts all the resources and about ~30s after the debug session crashes with no significant errors. The AppHost and all resources exit with code 0 with no Exceptions regardless of LogLevel and did not find anything that looked relevant on the C# Dev Kit logs or the C# extension logs.

https://github.com/user-attachments/assets/1094343d-c422-4758-a7b9-a789027ad030

Expected Behavior

Aspire Debug session starts and continues succesfully.

Steps To Reproduce

  • Right click on App Host in VS Code
  • Select Debug -> Start New Instance
  • The project will run, the dashboard launches, the resources are created
  • After a short while after all the resources are created the debug session crashes

Attached video of issue, if you need any other information let me know.

Exceptions (if any)

info: Aspire.Hosting.DistributedApplication[0] Login to the dashboard at https://localhost:17112/login?t=13d1f849fecd488c89282d540bb7d692 info: Aspire.Hosting.DistributedApplication[0] Distributed application started. Press Ctrl+C to shut down. Aspire.Hosting.DistributedApplication: Information: Distributed application started. Press Ctrl+C to shut down. The program '[359961] Prdh.AppHost' has exited with code 0 (0x0).

.NET Version info

.NET SDK: Version: 9.0.100-rc.1.24452.12 Commit: 81a714c6d3 Workload version: 9.0.100-manifests.a7bf2b8f MSBuild version: 17.12.0-preview-24422-09+d17ec720d

Runtime Environment: OS Name: ubuntu OS Version: 24.04 OS Platform: Linux RID: linux-x64 Base Path: /usr/share/dotnet/sdk/9.0.100-rc.1.24452.12/

.NET workloads installed: Configured to use loose manifests when installing new manifests. There are no installed workloads to display.

Host: Version: 9.0.0-rc.1.24431.7 Architecture: x64 Commit: static

.NET SDKs installed: 8.0.402 [/usr/share/dotnet/sdk] 9.0.100-rc.1.24452.12 [/usr/share/dotnet/sdk]

.NET runtimes installed: Microsoft.AspNetCore.App 8.0.8 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 9.0.0-rc.1.24452.1 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 8.0.8 [/usr/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 9.0.0-rc.1.24431.7 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found: None

Environment variables: Not set

global.json file: Not found

Learn more: https://aka.ms/dotnet/info

Download .NET: https://aka.ms/dotnet/download

Anything else?

  • Running on Github Codespace with dotnet devcontainer - 8 vcpu with 32 GB RAM
  • Can replicate on both VS Code and VS Code Insiders
  • Can replicate with both the Release and Prerelease versions of C# and C# DevKit extensions
  • No errors found in the C# and C# Dev Kit logs
  • Executing via 'dotnet run' works fine

gabynevada avatar Oct 01 '24 02:10 gabynevada

@timheuer @bradygaster this sound familiar? Did we have someone else report issues with Aspire debugging in VS Code with codespaces?

DamianEdwards avatar Oct 03 '24 23:10 DamianEdwards

Yes. @webreidi heres an issue to use.

timheuer avatar Oct 04 '24 13:10 timheuer

It would be good to know if its the apphost crashing first. If the apphost goes down then everything else will.

It would also be good to get some sense of the memory utilization.

mitchdenny avatar Oct 08 '24 05:10 mitchdenny

@mitchdenny I can get the memory utilization. Is there a way I can turn on more detailed logging for the debugger or a preferred method to time which one crashes first?

We don't get anything meaningful in the C# Dev Kit or C# extension logs.

gabynevada avatar Oct 08 '24 13:10 gabynevada

Adding the memory usage recording but I think I found what area is crashing the debug processes.

https://github.com/user-attachments/assets/a881ef2e-cc62-4fc3-b340-06fbbf25d750

gabynevada avatar Oct 09 '24 23:10 gabynevada

Found that if I exclude one of the worker projects from the AppHost, it does not crash when debugging. The project has a try catch with a switch statement that throws if there's not a case handling the value for the switch, it catches the error and then it just logs and continues the execution.

If there's an exception in another function that the switch executes it keeps working fine but the exception from the unhandled switch causes the worker and everything else to crash. If I run via the terminal the worker functions as expected, it just logs the error and continues running.

Here's a sample:

      try
      {
        var exportResult = pendingExportSchedule.ExportType switch
        {
          "DataSource1" => await ExportDataSource1(dataEndDate),
          "DataSource2" => await ExportDataSource2(stoppingToken),
          _ => throw new Exception($"Invalid export type: {pendingExportSchedule.ExportType}"),  // Crashes at this point, does not even get to the catch in debug mode
        };
      }
      catch (Exception e)
      {
        logger.LogError(
          e,
          "Error processing export type {ExportType}",
          pendingExportSchedule.ExportType
        );
      }

In this case there's no exception that crashes the program itself, but even if there was shouldn't the app host continue running and just update the resource as Failed?

Once this exception is thrown the worker crashes, does not log any Exceptions and causes the AppHost and all other resources to exit with code 0.

I'll see if I can replicate using a minimal sample to post here.

gabynevada avatar Oct 09 '24 23:10 gabynevada

Yes if one of the processes dies the apphost should continue to run. Let me see if I can repro this.

mitchdenny avatar Oct 10 '24 01:10 mitchdenny

Can you put together a repro of what you are seeing in a GitHub repo and share the link. I am having trouble reproducing what you are seeing so I want to make sure I've got everything arranged the way you do.

mitchdenny avatar Oct 10 '24 01:10 mitchdenny

Closing this issue as we can't repro this and we don't have a repro repo. If you are still seeing this with 9.0 or 9.1 bits please let us know.

mitchdenny avatar Feb 25 '25 01:02 mitchdenny