adding ComputeSeparation Aspire AppHost - #12016
Open
Brett Samblanet (brettsam) wants to merge 1 commit into
Open
adding ComputeSeparation Aspire AppHost#12016Brett Samblanet (brettsam) wants to merge 1 commit into
Brett Samblanet (brettsam) wants to merge 1 commit into
Conversation
Copilot started reviewing on behalf of
Brett Samblanet (brettsam)
September 11, 2026 01:01
View session
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Unresolved critical and moderate findings remain.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Adds an Aspire-based local harness for exercising the Functions Host, WorkerProxy, and isolated worker in project and container modes.
Changes:
- Adds Aspire orchestration, Compose topologies, and worker linking.
- Adds isolated sample worker and container images.
- Integrates the tooling into the solution while keeping CI product-focused.
File summaries
| File | Change | Review finding |
|---|---|---|
tools/ComputeSeparation/WorkerProxy/Dockerfile.dockerignore |
WorkerProxy build-context exclusions | — |
tools/ComputeSeparation/WorkerProxy/Dockerfile |
Native AOT WorkerProxy image | — |
tools/ComputeSeparation/worker-pod.compose.yaml |
WorkerProxy/worker pod topology | Moderate (1 vote): Add readiness gating or supervision so the worker cannot lose its initial connection while the pod reports healthy. |
tools/ComputeSeparation/SampleIsolatedApp/SampleIsolatedApp.csproj |
Isolated worker project configuration | Moderate (2 votes): Enable FunctionsEnableWorkerIndexing for Host metadata discovery. |
tools/ComputeSeparation/SampleIsolatedApp/README.md |
Sample usage documentation | Nit (3 votes): Document standalone build, publish, run, networking, shutdown, image, and validation workflows. |
tools/ComputeSeparation/SampleIsolatedApp/Program.cs |
Worker startup | — |
tools/ComputeSeparation/SampleIsolatedApp/host.json |
Default worker configuration | — |
tools/ComputeSeparation/SampleIsolatedApp/Hello.cs |
HTTP Hello function | Moderate (2 votes): Add focused metadata and response coverage or a bounded real-worker smoke test. |
tools/ComputeSeparation/SampleIsolatedApp/Dockerfile.dockerignore |
Sample image context exclusions | — |
tools/ComputeSeparation/SampleIsolatedApp/Dockerfile |
Sample worker image | Critical (3 votes): Preserve worker.config.json and functions.metadata in /publish. |
tools/ComputeSeparation/runtime.compose.yaml |
Host runtime topology | — |
tools/ComputeSeparation/README.md |
Harness usage documentation | — |
tools/ComputeSeparation/FunctionsHost/Dockerfile.dockerignore |
Host build-context exclusions | — |
tools/ComputeSeparation/FunctionsHost/Dockerfile |
ReadyToRun Host image | — |
tools/ComputeSeparation/Directory.Packages.props |
Aspire package versioning | — |
tools/ComputeSeparation/AppHost/Properties/launchSettings.json |
Project and container profiles | — |
tools/ComputeSeparation/AppHost/Program.cs |
Aspire resource orchestration | — |
tools/ComputeSeparation/AppHost/HostLinkService.cs |
Automatic worker linking | — |
tools/ComputeSeparation/AppHost/HarnessRunDirectory.cs |
Temporary run directories | — |
tools/ComputeSeparation/AppHost/ContainerTopology.cs |
Container lifecycle ownership | — |
tools/ComputeSeparation/AppHost/ComputeSeparation.AppHost.csproj |
AppHost configuration | Moderate (1 vote): Align the implementation with the required harness-only Rpc.Client/MockWorker topology or revise the issue linkage and scope. |
tools/ComputeSeparation/AppHost/ComposeSession.cs |
Compose lifecycle management | — |
eng/ci/templates/jobs/run-linux-tests.yml |
Product-only Linux CI test selection | — |
Azure.Functions.Host.slnx |
Includes AppHost and sample | Moderate (1 vote): Keep harness projects in the focused ComputeSeparation solution rather than the shipping solution. |
.gitignore |
Local Aspire configuration exclusions | — |
Review details
Suppressed comments (3)
Azure.Functions.Host.slnx:23
- #11976 explicitly requires a focused
tools/ComputeSeparation/ComputeSeparation.slnxand says not to add harness projects to shipping solutions. Adding these projects toAzure.Functions.Host.slnxviolates that isolation; it also causes a normal non-design AppHost build to runPrepareAspireCliBundleand bootstrap Aspire viadotnet dnx ... setup. Move the tool projects to the focused solution or revise the requirement.
<Folder Name="/tools/ComputeSeparation/">
<Project Path="tools/ComputeSeparation/AppHost/ComputeSeparation.AppHost.csproj" />
<Project Path="tools/ComputeSeparation/SampleIsolatedApp/SampleIsolatedApp.csproj" />
tools/ComputeSeparation/AppHost/ComputeSeparation.AppHost.csproj:24
- The linked #11976 requires the first Aspire slice to use a harness-only Rpc.Client driver and MockWorker, explicitly excluding
SampleIsolatedApp, the real compute Host/ScriptHost, and production composition. These references wire the real Host and sample instead, with no client-driver/MockWorker resources or smoke project, so this PR does not implement the issue it claims to resolve; please revise the linkage/scope or add that required topology.
<ProjectReference Include="..\..\..\src\Functions.Host\Functions.Host.csproj" />
<ProjectReference Include="..\..\..\src\Functions.WorkerProxy\Functions.WorkerProxy.csproj" />
<ProjectReference Include="..\SampleIsolatedApp\SampleIsolatedApp.csproj" />
tools/ComputeSeparation/worker-pod.compose.yaml:22
depends_ononly orders container creation; it does not wait for WorkerProxy's management or worker-facing listener to be ready. The Aspire health check probes only the proxy, so the isolated worker can start and lose its initial FunctionRpc connection while the pod is still reported healthy, after whichHostLinkServicehas no retry path. Add a readiness gate/supervision strategy so the worker starts only after the proxy is accepting connections, or make the pod health signal include the worker.
network_mode: service:worker-proxy
depends_on:
- worker-proxy
- Files reviewed: 24/25 changed files
- Comments generated: 4
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+9
to
+11
| RUN dotnet publish SampleIsolatedApp.csproj --configuration Release --runtime linux-x64 --self-contained false \ | ||
| -p:PublishReadyToRun=true --output /publish \ | ||
| && rm -f /publish/worker.config.json /publish/functions.metadata |
Comment on lines
+20
to
+21
| [Function(nameof(Hello))] | ||
| public IActionResult Run([HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = "hello")] HttpRequest request) |
Comment on lines
+8
to
+9
| <Nullable>enable</Nullable> | ||
| <UseAppHost>false</UseAppHost> |
Comment on lines
+5
to
+9
| ## Run | ||
|
|
||
| Follow the [ComputeSeparation run instructions](../README.md), select the `project` or `container` launch profile, and press F5. | ||
|
|
||
| This project does not start its own Functions Host. The Aspire tool starts the Host and WorkerProxy and links the worker automatically in both modes. |
7 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves #11976, #12008
Partially addresses #11975, #11977, #11978 (will complete these in follow-ups)
Adds an Aspire 13.5.3 AppHost for manually exercising compute separation locally with the real Functions Host, WorkerProxy, and a .NET isolated sample app. No product code changes are included.
Local development
Set
ComputeSeparation.AppHostas the startup project inAzure.Functions.Host.slnx, select a profile, and press F5:projectcontainerBoth profiles launch the Aspire dashboard and automatically link the worker through the Host's
PUT /admin/workersendpoint. GET and POST requests to the Host's/api/helloexercise the real Host → WorkerProxy → worker flow.Neither mode requires Core Tools, image publication, or an Aspire deployment command. The tool uses the Host's existing read-only app-content configuration rather than generating or mounting a Host
host.json.Independent container lifecycle
Container mode exposes two separate Aspire resources and Compose projects:
runtime: owns the Host container and shared Docker network.worker-pod-1: owns the WorkerProxy/worker pair. Stopping it removes the pod without stopping the Host.The Proxy and worker share a network namespace so the Proxy can reach the worker's loopback-only HTTP listener. A small Compose adapter provides this arrangement because Aspire's native container networking conflicts with shared network namespaces.
The pod definition is reusable for additional independently named pods. Normal shutdown removes the pod before the runtime and its network. Dynamic pod creation, automatic relinking, and invocation readiness for later-linked workers remain outside this change.
Build integration
Includes the AppHost and sample in the main solution. Linux CI continues building and running the product test projects directly, without bootstrapping the manual Aspire toolchain. No topology test project is added.
Pull request checklist
IMPORTANT: Currently, changes must be backported to the
in-procbranch to be included in Core Tools and non-Flex deployments.in-procbranch is not requiredrelease_notes.md