Current State:
Clients call POST /rest/api/3/issue/bulkfetch with Assets/CMDB fields in expand (for example customfield_10xxx.cmdb.attributes). Jira then calls the Assets POST /api/v1/object/bulk endpoint to hydrate the Assets data.

When the Assets call is rate‑limited (429), Assets correctly returns 429 with Retry-After and X-RateLimit-* headers, but Jira:

• Swallows this detail,
• Returns 200 OK from /issue/bulkfetch, and
• Silently omits the hydrated Assets data from the response.

From the caller’s point of view, Assets data is simply missing or partial, with no indication whether this is due to customer configuration, data state, or an internal CMDB/Assets hydration error such as rate limiting. This caused multiple JXL Cloud customers to “lose” Assets data during a ~30x traffic spike, even though the problem self‑resolved once traffic went back to baseline.

Proposed Future State:
When CMDB/Assets hydration fails during /rest/api/3/issue/bulkfetch:

• Jira keeps returning partial results with 200 where appropriate, but:
• Adds clear, structured error metadata for each issue/field where Assets hydration failed (e.g. error code, downstream status like 429, brief reason).
• When the failure is due to Assets rate limiting, propagates relevant rate‑limit headers (Retry-After, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) to the caller.

This allows clients to:

• Tell “no data” apart from “temporary hydration failure”,
• Inform users correctly, and
• Implement proper retry/backoff behaviour.

Alternative (e.g. Third Party Plugin):
No third‑party plugin can fix this, as the issue is in how Jira exposes downstream failures in the /issue/bulkfetch response.