Summary
The emulator silently accepts SearchIndexClient.CreateOrUpdateIndexAsync calls that mutate attributes on existing fields. Real Azure AI Search rejects the same calls with HTTP 400 and a message like:
Existing field 'Id' cannot be changed.
This causes code that passes locally against the emulator to fail in production against the real service.
Affected behavior
On real Azure AI Search, the following field changes on an existing field are not allowed via CreateOrUpdate and require deleting and recreating the index:
- Changing
Type
- Toggling
IsKey, IsFilterable, IsFacetable, IsSortable, IsSearchable, IsHidden
- Changing
AnalyzerName
- Removing a field that previously existed
The emulator currently accepts requests that include any of these changes and returns success, so the index appears to update when it would have been rejected by Azure.
Reproduction
Using Azure.Search.Documents 11.7.0 against the emulator:
- Create an index with a single field
Title (SearchFieldDataType.String, IsFilterable = false).
- Call
CreateOrUpdateIndexAsync with the same index name but with Title.IsFilterable = true.
- Observe: emulator returns 200/201. Against real Azure AI Search, the same call returns 400 with
Existing field 'Title' cannot be changed.
The same divergence reproduces for type changes (e.g. String → Int32), removed fields, and IsKey/IsHidden/analyzer changes on existing fields.
Expected behavior
CreateOrUpdateIndexAsync should reject any change to an existing field's immutable attributes with the same error shape Azure returns, so consumers can detect breaking schema diffs locally and switch to a delete-and-recreate path.
Impact
The leniency masks bugs in dev/CI that only surface once code reaches a real Azure AI Search instance, where an indexer can get stuck in a perpetual failure loop (every tick re-sends the rejected CreateOrUpdate and never advances). Matching Azure's stricter behavior would let consumers catch this in unit/integration tests against the emulator.
Environment
- SDK:
Azure.Search.Documents 11.7.0
- API operation:
Indexes - Create Or Update
Summary
The emulator silently accepts
SearchIndexClient.CreateOrUpdateIndexAsynccalls that mutate attributes on existing fields. Real Azure AI Search rejects the same calls with HTTP 400 and a message like:This causes code that passes locally against the emulator to fail in production against the real service.
Affected behavior
On real Azure AI Search, the following field changes on an existing field are not allowed via
CreateOrUpdateand require deleting and recreating the index:TypeIsKey,IsFilterable,IsFacetable,IsSortable,IsSearchable,IsHiddenAnalyzerNameThe emulator currently accepts requests that include any of these changes and returns success, so the index appears to update when it would have been rejected by Azure.
Reproduction
Using
Azure.Search.Documents11.7.0 against the emulator:Title(SearchFieldDataType.String,IsFilterable = false).CreateOrUpdateIndexAsyncwith the same index name but withTitle.IsFilterable = true.Existing field 'Title' cannot be changed.The same divergence reproduces for type changes (e.g.
String→Int32), removed fields, andIsKey/IsHidden/analyzer changes on existing fields.Expected behavior
CreateOrUpdateIndexAsyncshould reject any change to an existing field's immutable attributes with the same error shape Azure returns, so consumers can detect breaking schema diffs locally and switch to a delete-and-recreate path.Impact
The leniency masks bugs in dev/CI that only surface once code reaches a real Azure AI Search instance, where an indexer can get stuck in a perpetual failure loop (every tick re-sends the rejected
CreateOrUpdateand never advances). Matching Azure's stricter behavior would let consumers catch this in unit/integration tests against the emulator.Environment
Azure.Search.Documents11.7.0Indexes - Create Or Update