Flex Consumption: maximumInstanceCount not enforced for HTTP triggers, host.json HTTP settings ignored

Bug Description

On the Flex Consumption plan, maximumInstanceCount is not enforced as a hard limit for HTTP trigger scaling. Additionally, host.json HTTP settings (maxConcurrentRequests, maxOutstandingRequests) are silently ignored.

When sending burst HTTP traffic that exceeds perInstanceConcurrency, the platform scales well beyond maximumInstanceCount, creating 30-60+ transient instances even when maximumInstanceCount is set to 1.

Configuration

// functionAppConfig.scaleAndConcurrency (via REST API / Azure CLI)
{
  "alwaysReady": [{"instanceCount": 1, "name": "http"}],
  "instanceMemoryMB": 2048,
  "maximumInstanceCount": 1,
  "triggers": {
    "http": {
      "perInstanceConcurrency": 200
    }
  }
}

// host.json
{
  "version": "2.0",
  "functionTimeout": "00:10:00",
  "extensions": {
    "http": {
      "maxConcurrentRequests": 500,
      "maxOutstandingRequests": 1000,
      "dynamicThrottlesEnabled": false
    }
  }
}

Reproduction Steps

1. Create a Flex Consumption function app (Python 3.10, ASGI/FastAPI)
2. Set maximumInstanceCount: 1, alwaysReady: 1, perInstanceConcurrency: 200
3. Send 300+ concurrent HTTP requests using a simple load test script
4. Query Application Insights:

requests 
| where timestamp > ago(10m) 
| summarize count() by cloud_RoleInstance 
| order by count_ desc

5. Observe 30+ unique cloud_RoleInstance values, even though maximumInstanceCount is 1

Expected Behavior

• With maximumInstanceCount: 1 and perInstanceConcurrency: 200, requests beyond 200 concurrent should either queue or return HTTP 429 — not spin up additional instances.
• host.json HTTP settings (maxConcurrentRequests, maxOutstandingRequests) should be respected on Flex Consumption, or the documentation should clearly state they are ignored.

Actual Behavior

• 30-60+ unique cloud_RoleInstance IDs appear in Application Insights within minutes
• Multiple instances handle requests simultaneously (not recycled workers — verified via per-second dcount)
• host.json HTTP throttle settings have zero effect

Root Cause (Code Evidence)

In HttpOptionsSetup.cs, HTTP throttling defaults are only configured for Windows Consumption:

public void Configure(HttpOptions options)
{
    if (_environment.IsWindowsConsumption())  // ← No Flex Consumption branch
    {
        options.DynamicThrottlesEnabled = true;
        options.MaxConcurrentRequests = DefaultMaxConcurrentRequests;
        options.MaxOutstandingRequests = DefaultMaxOutstandingRequests;
    }
}

There is no IsFlexConsumptionSku() branch. On Flex Consumption, MaxConcurrentRequests and MaxOutstandingRequests default to DataflowBlockOptions.Unbounded, which means the HttpRequestQueue (source) is never enabled:

public static bool IsEnabled(HttpOptions httpOptions)
{
    return httpOptions.MaxOutstandingRequests != DataflowBlockOptions.Unbounded ||
           httpOptions.MaxConcurrentRequests != DataflowBlockOptions.Unbounded;
}

This means user-configured host.json values for HTTP throttling are parsed but overridden, and the worker host accepts unlimited concurrent requests. The external scale controller then sees high concurrency and scales out beyond maximumInstanceCount.

Documentation Gap

• The host.json HTTP settings docs list defaults for Consumption, Premium, and Dedicated — but do not mention Flex Consumption at all.
• The Flex Consumption deprecations table deprecates FUNCTIONS_MAX_HTTP_CONCURRENCY but does not mention host.json HTTP settings.
• The event-driven scaling docs describe maximumInstanceCount as a limit but don't clarify whether it's a hard or soft limit for HTTP triggers during bursts.

Questions

1. Is maximumInstanceCount intended to be a hard ceiling for HTTP triggers, or a soft target?
2. Should host.json HTTP settings (maxConcurrentRequests, maxOutstandingRequests) be respected on Flex Consumption?
3. Are the 30+ cloud_RoleInstance values actual billable instances, or internal platform routing artifacts?

Environment

• Plan: Flex Consumption (SKU: FlexConsumption)
• Runtime: Python 3.10 (ASGI model with FastAPI)
• Region: East US
• Extension Bundle: [4.*, 5.0.0)

Start with src/WebJobs.Script.WebHost/Configuration/HttpOptionsSetup.cs and HttpRequestQueue.cs, then reproduce the Flex Consumption behavior using the listed configuration and concurrent HTTP load. Check Application Insights for instance counts and compare the observed handling with the documented maximumInstanceCount and host.json HTTP settings. Done means the intended limit behavior is established and either the settings are enforced or the Flex Consumption documentation clearly explains their behavior.