AddNpm App ResourceStop not working

[swissarmykirpan]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I am executing the SWA CLI via NPM

      builder.AddNpmApp("swa", "app", "swa")
          .WithReference(api)
          .WithHttpEndpoint(targetPort: 4280);

Everything works fine on first startup. However when I stop Visual Studio, the node process is still running. Also if I press the stop button on the dashboard, it reports:

2024-10-10T02:25:19 Executing command 'resource-stop'.
2024-10-10T02:25:19 Successfully executed command 'resource-stop'.

but the node process is still running and the url continues to accept traffic.

This is not occurring in the 8.2.0 Nuget Packages and SDK.

Expected Behavior

The executable ends on close or when the stop button is pressed

Exceptions (if any)

No exceptions are being thrown. Silent failure

.NET Version info

Sdk Version: 9.0.0-rc.1.24506.1
.NET 8.0.400
Windows 11 23H2

Ive tried both:

npm: 8.11.0, node: 16.16.0
npm: 10.8.2, node: 20.18.0

fails on windows.

Works on WSL.

[davidfowl]

Static web apps CLI? Is that what the SWA CLI is? Can you share a project that we can use to reproduce the issue?

[swissarmykirpan]

Sorry, to clarify it doesn’t matter what the underlying npm task does (call swa cli or webpack), the behaviour is the same.

I’ll create a shareable project.

[swissarmykirpan]

@davidfowl https://github.com/swissarmykirpan/aspire-swa, i've got two examples here, one using the swa cli and the other using another npm package called http-server. Same outcomes.

[danegsta]

I think I understand what's causing this issue; npm shares its stdio with its forked children, but when we kill npm it isn't killing all the children automatically. Unfortunately we're also waiting on the stdio to finish flushing. We need to start cleaning up the children in parallel while we wait for stdio to close.

[danegsta]

Yeah, this is purely an orchestrator bug; I've got a fix that can go into the next DCP insertion.

[swissarmykirpan]

@davidfowl @danegsta any indication of when this will make it out to the nighty build?

[danegsta]

It should already be in the latest nightly builds; looks like several CI runs have completed since the fix was merged.

[zejji]

I'm still seeing this issue in 9.0.0-rc.1.24511.1

I've followed the instructions to get daily builds and can't see any more recent versions than this when I check for updated packages in Visual Studio.

I don't know whether it's relevant, but I also have other npm projects running at the same time on my computer which aren't managed by Aspire.

It would be very helpful if this situation is handled correctly as I often need to work on both a .NET Aspire project and a non-.NET Aspire project simultaneously. It will also prove to be very confusing behavior for more junior team-mates.

[danegsta]

The rc.1 builds are from a separate release candidate branch that was forked before this fix was merged. Nightly builds from main should now be on 9.0.0-rc.2.