Issue Summary

The indexing thread monitor incorrectly reports a BROKEN state when the indexing queue is empty (queueSize: 0) and the thread has been idle longer than the unresponsive timeout (~30 minutes by default). This is a false positive in the monitoring logic. Actual search indexing functionality is not affected. Events are polled and processed correctly. Only the reported status is incorrect.

This means the BROKEN state is inevitable and deterministic. Any Bitbucket instance that has no indexing activity for longer than the unresponsive timeout (e.g. overnight, weekends, or low-traffic periods) will be incorrectly flagged as BROKEN.

Steps to Reproduce

1. Set up a Bitbucket instance with OpenSearch search enabled
2. Allow the indexing queue to fully drain (queueSize: 0) with no new indexing events
3. Wait for the unresponsive timeout to elapse (~30 minutes by default)
4. Check the indexing thread state via /rest/indexing/latest/support-info

Expected Results

The indexing thread is reported as IDLE when the queue is empty and the thread is not processing any events.

Actual Results

The indexing thread is reported as BROKEN with the following description:

{
  "state": {
    "code": "BROKEN",
    "description": "The indexing thread is currently idle, has been unresponsive since <timestamp>, and the queue is not empty. This indicates that something is blocking the thread from polling items from the queue."
  },
  "queueSize": 0
}

This is a false positive. The queue is actually empty and the thread is healthy.

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available