[BUG] Azure.Search.Documents 12.0.0: untyped IndexingParametersConfiguration keys (e.g. assumeOrderByHighWaterMarkColumn) are silently dropped when creating/updating an indexer #10405

Library name and version

Azure.Search.Documents 12.0.0 (worked in 11.x)

Describe the bug

IndexingParametersConfiguration still implements IDictionary<string, object> and accepts Add(key, value), but since 12.0.0 these keys are no longer sent to the service. SearchIndexerClient.CreateOrUpdateIndexerAsync(SearchIndexer) serializes the model in wire format ("W"), which writes only the typed properties; keys added via Add(...) and also additional properties passed via SearchModelFactory.IndexingParametersConfiguration(additionalProperties: ...) are omitted. The service receives "configuration": {}.

This affects documented configuration keys that have no typed property, most importantly assumeOrderByHighWaterMarkColumn for Cosmos DB indexers with a custom query (https://learn.microsoft.com/azure/search/search-howto-index-cosmosdb#incremental-indexing-and-custom-queries). Without it the indexer reports "The current indexer configuration does not support incremental progress" and restarts from the beginning after every timeout, so indexers with a skillset (2 h limit) never finish on large collections.

The failure is silent: no exception, no warning, the call succeeds.

Expected behavior

Keys added to IndexingParametersConfiguration (or passed as additional properties) are sent in the request body, as in 11.x, e.g. "configuration": {"assumeOrderByHighWaterMarkColumn": true}.

Actual behavior

"configuration": {} is sent; a following GET /indexers/{name} shows an empty configuration.

Reproduction Steps

using System.ClientModel.Primitives;
using Azure.Search.Documents.Indexes.Models;
using Azure.Search.Documents.Models;

var indexer = new SearchIndexer("x", "ds", "idx")
{
    Parameters = new IndexingParameters { IndexingParametersConfiguration = new IndexingParametersConfiguration() }
};
indexer.Parameters.IndexingParametersConfiguration.Add("assumeOrderByHighWaterMarkColumn", true);
Console.WriteLine(ModelReaderWriter.Write(indexer, new ModelReaderWriterOptions("W")));
// {"name":"x","dataSourceName":"ds","targetIndexName":"idx","parameters":{"configuration":{}}}

indexer.Parameters.IndexingParametersConfiguration = SearchModelFactory.IndexingParametersConfiguration(
    additionalProperties: new Dictionary<string, BinaryData> { ["assumeOrderByHighWaterMarkColumn"] = BinaryData.FromObjectAsJson(true) });
Console.WriteLine(ModelReaderWriter.Write(indexer, new ModelReaderWriterOptions("W")));
// {"name":"x","dataSourceName":"ds","targetIndexName":"idx","parameters":{"configuration":{}}}
// (format "J" contains the key, but the client sends "W")

Against a real service: await client.CreateOrUpdateIndexerAsync(indexer); then GET /indexers/x returns "configuration": {}.

Environment

.NET 10, Windows / Azure Functions isolated worker, Azure.Search.Documents 12.0.0, service api-version 2026-04-01 (SDK default).

Additional context

• The protocol overload CreateOrUpdateIndexerAsync(string, RequestContent, MatchConditions, RequestContext) is internal in 12.0.0, so there is no supported way to send the key. Our workaround: serialize with "W", add the key with JsonNode and send a PUT indexers('name') through SearchIndexerClient.Pipeline.
• A GET-then-PUT round trip of an existing indexer also drops keys that were set via the portal/REST.
• Suggested fix: serialize the dictionary entries / additional properties of IndexingParametersConfiguration in wire format (the service accepts arbitrary configuration keys), or add a typed AssumeOrderByHighWaterMarkColumn property and make the protocol method public.