Fix worker process count not respecting MaxProcessCount on high core count machines

[sarah (satvu)]

Summary

Fixes #8014

When SetProcessCountToNumberOfCpuCores is true, the GetWorkerProcessCount method was setting ProcessCount to the raw core count and then raising MaxProcessCount to match if cores exceeded the configured max. This meant MaxProcessCount was silently overridden on high core count machines (e.g., 32+ cores).

Changes

WorkerConfigurationProviderBase.cs — replaced the two-line block that set ProcessCount = coresCount and conditionally raised MaxProcessCount with a single line:

workerProcessCount.ProcessCount = Math.Min(coresCount, workerProcessCount.MaxProcessCount);

MaxProcessCount is now a hard ceiling that is never overridden.

WorkerConfigurationProviderBaseTests.cs — updated the GetWorkerProcessCount_Tests assertion to expect Math.Min(coresCount, maxProcessCount) instead of the raw core count, so the test passes correctly regardless of the machine's core count.

Testing

All 5 GetWorkerProcessCount tests pass.

Checklist

• Backporting to the in-proc branch is not required
  • Otherwise: Link to backporting PR
• My changes do not require documentation changes
  • Otherwise: Documentation issue linked to PR
• My changes should not be added to the release notes for the next release
  • Otherwise: I've added my notes to release_notes.md
• My changes do not need to be backported to a previous version
  • Otherwise: Backport tracked by issue/PR #issue_or_pr
• My changes do not require diagnostic events changes
  • Otherwise: I have added/updated all related diagnostic events and their documentation (Documentation issue linked to PR)
• I have added all required tests (Unit tests, E2E tests)

[Copilot]

Pull request overview

Fixes an issue in WorkerConfigurationProviderBase.GetWorkerProcessCount where enabling SetProcessCountToNumberOfCpuCores could effectively override a configured MaxProcessCount on high core-count machines by raising the max to match the detected core count.

Changes:

• Clamp ProcessCount to Math.Min(effectiveCores, MaxProcessCount) when SetProcessCountToNumberOfCpuCores is enabled.
• Update the corresponding unit test assertion to expect the clamped value rather than the raw core count.
• Add a release note entry describing the fix.

Reviewed changes

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

File	Description
src/WebJobs.Script/Workers/Rpc/Configuration/WorkerConfigurationProviderBase.cs	Ensures MaxProcessCount remains a hard ceiling when deriving ProcessCount from effective CPU cores.
test/WebJobs.Script.Tests/Workers/Rpc/WorkerConfigurationProviderBaseTests.cs	Updates the SetProcessCountToNumberOfCpuCores expectation to match the new clamping behavior.
release_notes.md	Documents the fix in the release notes list.

[Brett Samblanet (brettsam)]

/azp run host.integration-tests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Brett Samblanet (brettsam)]

Azure Pipelines successfully started running 1 pipeline(s).

Sorry sarah (@satvu) -- put that in the wrong PR...