Diagnose an accepted document missing from search

Understand the likely causes

• The bulk item may have failed inside a successful transport response, the writer may target another index, or the field may be ignored or analyzed differently from the query. A recent accepted write can also be waiting for search refresh. These are distinct layers with different evidence.

Establish the item’s actual outcome

For a bulk request, inspect errors and every ordered item result. HTTP 200 only establishes a delivered bulk response. Correlate the artifact with its action metadata and preserve mapping or pipeline rejection details. If connection loss leaves the outcome unknown, reconcile through the stable identifier instead of allocating a new one and resending blindly. Count accepted, rejected, retryable and unresolved records against the submitted actions. An artifact whose source was already deleted may be impossible to repair without a durable producer checkpoint.

Confirm the exact logical and concrete target

Compare the writer’s index or alias with the reader’s target and the current approved alias configuration. The same _id can exist in several indices. A versioned-index migration can leave one client writing directly to v1 while readers resolve v2. The schematic response below proves only the indicated synthetic target and item result; it does not prove the catalog alias searches it. Review routing as well when the application uses custom routing, and keep endpoint and credential details private.

{"_index":"museum-artifacts-v1","_id":"art-101","result":"created"}

Inspect mapping and query vocabulary

Read the field mapping through an authorized path. dynamic:false in the ordinary stored-source model can retain a field in _source without making it searchable. A text field may index lowercase tokens while a term query supplies an incompatible exact value. The Analyze API body isolates a title transformation; no request is performed here. A mapping change adding a multi-field does not rebuild older documents automatically, so test a historical artifact as well as a newly written one.

{"analyzer":"standard","text":"BRONZE compass"}

Separate a refresh delay from a permanent rejection

A real-time GET can see a write before search refresh exposes it. Confirm the same target and identifier, then inspect the documented refresh policy and the product freshness requirement. Do not force a refresh after every event as a universal repair: that can increase indexing work. If an authorized test requires read-after-write search visibility, use the supported refresh behavior with its documented limits and measure the complete pipeline. A rejected item never becomes searchable merely by waiting longer.

Keep it from recurring

• Maintain stable identities, per-item bulk accounting, explicit mappings, analyzer fixtures and an agreed freshness contract. Include old documents and alias migrations in integration reviews, and retain a recoverable source until downstream outcomes are reconciled.