When Assets performs a reindex — most commonly the full re-index that now runs on every node startup — the in-memory object/attribute index is cleared and progressively rebuilt from the database. This can take a significant amount of time on instances with a large amount of Assets data.

During this window:

• The Assets UI (object navigator) correctly shows a "reindex in progress" banner/progress bar, so users interacting with that screen know results may be incomplete.
• The Assets search REST API (AQL search and object search endpoints) has no equivalent safeguard. It queries the in-memory index directly, with no check against the reindex/lock state. A search request made during this window returns a normal HTTP 200 response containing whatever subset of objects/attributes has been re-added to the index so far — silently incomplete, with no error, warning, or indication that the index isn't fully built.

This affects any caller of the search API during the reindex window, including:

• Direct callers of the public Assets REST API
• JQL functions that reference Assets objects
• Jira issue fields/panels backed by Assets objects
• Third-party integrations querying Assets via the API

Because there is no signal returned to the caller, this can be mistaken for a data-integrity bug, missing objects, or a broken import, rather than a transient re-index-in-progress state — leading to unnecessary investigation and support cases.

Suggested improvement

Either (or both) of the following would resolve this:

1. Add an explicit indicator to search API responses while a reindex is in progress. For example, a response header (e.g. X-Assets-Reindex-InProgress: true) or a field in the JSON response body, so callers can detect and handle the partial-data condition programmatically (e.g. retry later, show a warning to the end user).

1. Optionally block/delay search requests until the index is ready, mirroring the UI's existing behavior. This could be an opt-in behavior (e.g. a query parameter or global config toggle) given that some customers may prefer partial results over a hard block, especially for large data sets where a full reindex could take a long time.

Either approach would give API/integration consumers parity with what the UI already communicates to interactive users, and would let the underlying "reindex in progress" state (already tracked internally by Assets for the write-lock and for the UI progress banner) also inform the read/search path.

Why this matters

• The reindex-on-startup behavior is now the default/unconditional path for all Data Center customers (the previous "restore from cache" file-based mechanism has been removed), so this window is guaranteed to occur on every restart, not an edge case.
• Without a signal, downstream consumers (automations, dashboards, integrations) may act on incomplete data without any way to know it's incomplete.

Related issues

• JSDSERVER-11974