[BUG] Continuously index documents in opensearch, but there is no change in the number of documents queried through the interface

[liuwz02]

Describe the bug

when i continuously index documents in opensearch, but there is no change in the number of documents queried through the interface _stats/docs,store. However, when I stopped indexing documents in opensearch, the number of documents returned by the interface suddenly increased.

Related component

Other

To Reproduce

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior

When I continue to index documents in opensearch and use the interface to query the number of documents, the interface should return the real-time number of documents in the current time index.
https://opensearch.org/docs/latest/api-reference/index-apis/stats/

Additional Details

Plugins
Please list all plugins currently enabled.

Screenshots
If applicable, add screenshots to help explain your problem.

Host/Environment (please complete the following information):

• OS: [e.g. iOS]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

[shwetathareja]

When you are indexing documents, the documents are not available for search immediately.

By default, OpenSearch refreshes indexes every second, i.e. segments are created and documents are available for search. OpenSearch only refreshes indexes that have received at least one search request in the last 30 seconds.
https://opensearch.org/docs/latest/tuning-your-cluster/performance/#index-refresh-interval

You can run continuous search and configure the refresh interval explicitly depending on how soon you want documents to be available for search.

[peternied]

[Triage - attendees 1 2 3 4 5]
@liuwz02 This sounds like it could also be related to search idle behavior. However, there is not enough detail in this issue to reproduce so we are going to close this issue.

@andrross Could you provide more details if there might be a related bug?

[andrross]

@liuwz02 This looks like the same issue as described in #11225.