The bundled Aspire CLI extracts a shared layout under ~/.aspire and then launches private binaries from that layout (for example aspire-managed and DCP). Today, flows such as aspire setup --force can rewrite that shared layout in place.
If one CLI instance is actively using the extracted layout while another instance runs aspire setup --force, the second instance can delete or replace files out from under the first. The resulting user-visible failure depends on timing and which file disappears first.
This appears to be broader than one specific error signature. Depending on timing, the failure can surface as missing files under ~/.aspire/managed, RPC connection failures, AppHost server startup failures, or CLR/bootstrap failures when the managed child process starts against an incomplete layout.
A simple repro with a bundled release install is:
while true; do ~/.aspire/bin/aspire setup --force; done
run concurrently with:
while true; do ~/.aspire/bin/aspire sdk dump; done
A few observations from local/container repros:
- Parallel cold-start extraction did not reproduce the issue. Deleting the layout and launching many concurrent bundled commands succeeded, which suggests the current extraction lock is doing its writer/writer job.
- Killing
aspire setup --force mid-extract left a broken top-level layout state, but the next command re-extracted and succeeded. That stranded state self-heals.
- The reproducible failure is live in-place mutation of the active shared layout while another process is using it.
So the deeper issue seems to be that the shared extracted layout is treated as mutable even while readers are active.
The expected behavior is that a bundled command should never observe a partially published or partially deleted shared layout. aspire setup --force should either wait until the layout is no longer in use, or publish a fully staged layout without exposing an in-between state to readers.
The likely direction is to stop mutating the live shared layout in place while another command may be using it. Staging plus a publish/use coordination model seems needed here.
The bundled Aspire CLI extracts a shared layout under
~/.aspireand then launches private binaries from that layout (for exampleaspire-managedand DCP). Today, flows such asaspire setup --forcecan rewrite that shared layout in place.If one CLI instance is actively using the extracted layout while another instance runs
aspire setup --force, the second instance can delete or replace files out from under the first. The resulting user-visible failure depends on timing and which file disappears first.This appears to be broader than one specific error signature. Depending on timing, the failure can surface as missing files under
~/.aspire/managed, RPC connection failures, AppHost server startup failures, or CLR/bootstrap failures when the managed child process starts against an incomplete layout.A simple repro with a bundled release install is:
run concurrently with:
A few observations from local/container repros:
aspire setup --forcemid-extract left a broken top-level layout state, but the next command re-extracted and succeeded. That stranded state self-heals.So the deeper issue seems to be that the shared extracted layout is treated as mutable even while readers are active.
The expected behavior is that a bundled command should never observe a partially published or partially deleted shared layout.
aspire setup --forceshould either wait until the layout is no longer in use, or publish a fully staged layout without exposing an in-between state to readers.The likely direction is to stop mutating the live shared layout in place while another command may be using it. Staging plus a publish/use coordination model seems needed here.