[http-client-csharp] Avoid retaining unused PipelineRequestHeadersExtensions for Azure request APIs

[live1206]

Description

The provider reference map retains PipelineRequestHeadersExtensions for Azure data-plane clients with prefixed dictionary headers even when the emitted request API is Azure.Core and never uses PipelineRequestHeaders.

Observed during full Azure SDK data-plane regeneration for PR #11288. The following new internal files are generated:

• sdk/storage/Azure.Storage.Files.Shares/src/Generated/Internal/PipelineRequestHeadersExtensions.cs
• sdk/storage/Azure.Storage.Queues/src/Generated/Internal/PipelineRequestHeadersExtensions.cs

Both helpers are internal and do not affect public API. The Storage projects build successfully when the files are removed.

Root cause

RestClientProvider.BuildHelperDependencyTypes hard-codes PipelineRequestHeadersExtensionsDefinition whenever an operation has a dictionary header with CollectionHeaderPrefix.

That dependency is correct for the default System.ClientModel PipelineRequestProvider, but not for Azure's request abstraction. The emitted Storage code uses Azure.Core RequestHeaders.Add(prefix, dictionary) instead, so the generated PipelineRequestHeaders helper is unused. The former Roslyn reference map pruned the unused type from the final compilation; the provider graph treats the hard-coded helper dependency as authoritative and retains it.

Proposed fix

Express the required collection-header helper as a capability/dependency of HttpRequestApi (or the selected request API implementation), rather than hard-coding the System.ClientModel helper in RestClientProvider.

• The default PipelineRequestProvider should report PipelineRequestHeadersExtensionsDefinition.
• Azure's request API should report no generated helper because Azure.Core supplies the applicable operation.
• Add coverage proving prefixed dictionary headers retain the helper only for request APIs that require it.

Validation

A targeted local regeneration of Azure.Storage.Files.Shares and Azure.Storage.Queues reproduces both new files. Both SDKs regenerate and build successfully, and Azure.Storage.Queues also builds successfully after removing the generated helper.

[github-actions]

🎯 Issue Triage

The C# client emitter incorrectly retains a generated PipelineRequestHeadersExtensions helper for Azure data-plane clients that use Azure.Core request APIs, where the helper is unnecessary and unused.

Category: Bug
Area: emitter:client:csharp

🔍 Analysis

• Root cause: RestClientProvider.BuildHelperDependencyTypes unconditionally injects PipelineRequestHeadersExtensionsDefinition for any operation with a CollectionHeaderPrefix dictionary header, regardless of which request API implementation is selected. This was previously masked by Roslyn's dead-code pruning.
• Affected components: RestClientProvider, HttpRequestApi, PipelineRequestHeadersExtensionsDefinition in http-client-csharp.
• Impact: Low severity — generated files are internal and don't break builds, but they produce unnecessary code noise and diverge from expected SDK output.
• Proposed fix is well-scoped: Move the PipelineRequestHeadersExtensionsDefinition dependency to be a capability reported by each HttpRequestApi implementation, so only the System.ClientModel provider includes it and Azure's provider does not.

📝 Suggested next steps

• Refactor RestClientProvider.BuildHelperDependencyTypes to delegate collection-header helper dependencies to HttpRequestApi implementations.
• Ensure AzureHttpRequestApi (or equivalent) returns no generated helper for prefixed dictionary headers.
• Add test coverage confirming the helper is only emitted when the selected request API requires it.

Generated by Agentic Triage