Skip to content

CreateOrUpdateIndex accepts breaking field-attribute changes that real Azure AI Search rejects #32

@IndifferentDisdain

Description

@IndifferentDisdain

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:

  1. Create an index with a single field Title (SearchFieldDataType.String, IsFilterable = false).
  2. Call CreateOrUpdateIndexAsync with the same index name but with Title.IsFilterable = true.
  3. 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. StringInt32), 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions