[JanProvaznik]

Summary

This draft captures the V1 process-lifetime decisions for one shared MSBuild Server resident. MT and non-MT describe request modes, not different server types.

• The resident owns every worker and TaskHost it creates, whether it is serving an MT or non-MT request and whether it performs work itself or delegates it.
• Owned children may be reused while their owner remains alive, but they cannot migrate to another owner or outlive their owner.
• V1 keeps one resident server per compatible identity. Sequential requests reuse it.
• A busy reusable MT request and -mt -nodeReuse:false use one-build transient servers.
• A busy or unavailable non-MT request falls back to in-process execution and retains the legacy reconnectable worker pool.
• Resident idle expiration and dotnet build-server shutdown cascade through direct sidecars, owned workers, and worker-owned TaskHosts.
• Task execution and isolation guarantees do not change.

Documents

• documentation/specs/multithreading/server-taskhost-ownership.md
• documentation/specs/server-worker-node-ownership.md

Each spec is self-contained and defines the shared-resident and request-mode terminology it uses. The specs are intentionally limited to normative V1 ownership, reuse, shutdown, compatibility, and test requirements.

V1 decisions

1. There is one shared resident identity and endpoint. MT and non-MT are properties of individual requests.
2. The resident owns direct sidecars created while serving MT requests and workers created while serving non-MT requests.
3. Workers own the TaskHosts they create.
4. Owned nodes retain an ownership connection across reusable build boundaries and reset in place.
5. Explicitly transient TaskHosts remain transient for callers that require process isolation at the project-build boundary.
6. Multiple resident servers, dynamic downsizing, Server GC policy, and broader per-build state isolation are outside V1.

Deferred discussion kept out of the specs

RAR / service-node lifetime

The meeting identified service nodes as a separate node category but did not make a RAR ownership decision. RAR is therefore deliberately excluded from both specs.

Current implementation context:

• RAR is NodeMode 3, a global service process rather than a normal project worker.
• RarNodeLauncher discovers it through a stable lifecycle pipe and launches it only when absent.
• The process exposes multiple execution endpoints so independent clients can submit concurrent RAR requests.
• Its lifecycle pipe accepts reusable or terminal completion, while execution clients do not logically own the service.

Follow-up design questions:

• Should the shared resident own the RAR lifecycle, should the coordinator own it, or should it remain an explicitly global service?
• How should transient servers and in-process fallback requests access it without gaining lifecycle ownership?
• Which component sends terminal shutdown, and how does RAR participate in the system-wide idle guarantee?
• Does a shared RAR service need its own memory-pressure or idle-retirement policy?

No answer to those questions is implied by this PR.

Coordinator, multiple servers, and retained-node sizing

The ownership fix is intentionally not blocked on coordinator work. The meeting established a conservative V1 with one resident server because unconstrained resident servers can create severe process and memory growth in multi-agent scenarios.

Coordinator observations and future directions discussed:

• The existing coordinator does not solve idle-process memory pressure today.
• Multiple resident servers could eventually be enabled or limited by coordinator policy rather than being the default.
• A resident may retain more owned workers than a later coordinator grant permits. For example, a resident retaining 16 workers but granted 4 active nodes may need to park or terminate the other 12.
• Coordinator policy could tune both active core allocation and the amount of retained server/node capacity.
• An idle resident should eventually yield active cores so they can be redistributed without necessarily discarding warm processes.

Current coordinator protocol context:

• A request asks for nodes once, receives a fixed GrantedNodes value, sends heartbeats, and releases the grant at build completion.
• There is currently no dynamic grant-resize protocol.

Possible follow-up protocol, not proposed here:

• servers report changing runnable demand;
• idle servers yield active slots while retaining parked owned workers;
• the coordinator sends grow/shrink targets;
• shrinking stops new scheduling above the target and does not kill running work; and
• heartbeat loss revokes the lease and returns capacity.

Core leases and process ownership should remain separate concepts: the server owns process lifetime, while the coordinator governs how many logical execution slots may be active.

Related open follow-ups

• Define an owner-local downsizing policy for the large-request -> small-request -> concurrent-request scenario where unused resident-owned workers remain unavailable to another request.
• Preserve the existing idle expectation: after prolonged inactivity, MSBuild should reach zero process/resource use regardless of the last request mode.
• Consider staging TaskHost ownership before resident worker ownership because the worker path is broader.
• Long term, isolate static engine state into per-build state and consider per-build assembly-load boundaries. This is not required for V1 ownership.

Expected outcomes

• Correct server, worker, and TaskHost shutdown without enumerating resident-owned processes. Numbers TBD.
• Fast node and sidecar reuse within the resident ownership tree. Numbers TBD.
• No change to task execution/isolation guarantees.
• Server GC behavior is tracked separately. Numbers TBD.

Scope

Documentation and design discussion only; this PR contains no implementation changes.

Related to #14313.

[Copilot]

Pull request overview

Defines V1 ownership and lifetime rules for MSBuild Server–owned child processes (workers and TaskHosts), clarifying how MT vs non-MT requests route, reuse processes, and shut down cleanly without cross-owner adoption.

Changes:

• Adds a spec for MT request routing and TaskHost ownership, including resident vs transient server behavior and shutdown semantics.
• Adds a spec for resident ownership of non-MT worker nodes, including in-process fallback behavior and reuse/shutdown requirements.
• Links the existing multithreaded MSBuild spec to the new MT ownership/routing spec.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
documentation/specs/server-worker-node-ownership.md	New spec describing resident-owned worker lifetime for non-MT requests, fallback behavior, and required tests.
documentation/specs/multithreading/server-taskhost-ownership.md	New spec defining resident/transient routing for MT requests and TaskHost ownership/shutdown rules.
documentation/specs/multithreading/multithreaded-msbuild.md	Adds a cross-reference to the new MT routing/TaskHost ownership spec.