Sometime back when we created elastic we created multiple indexes with same initial pattern and these are dynamic suffix.
(eg : microservice_logs_XYZ , microservice_logs_abc , microservice_logs_pqr etc..)
Not sure the reason why our past team created in that fashion , probably to avoid indexing delays as log volumes are huge.
Now when we started implementing log processing using Python Client ( same is case with REST API) , we opted with 'Point In Time' pagination mode instead of 'Scroll After' as it was recommended by elastic.
Then we started going with creation of PIT ID using wildcard index (microservice_logs*), so it can search data requested from all indexes at once.
When we invoke python client/Rest call with search query using PIT ID , first 9999 records where good (as max search size was set to 10000) , when its going for second page (iteration) of PIT search - we are getting 404 status with below exception :
```
"type": "index_not_found_exception",
"reason": "no such index [microservice_logs_ABC-008127]",
"index_uuid": "na",
"resource.type": "index_expression"
My understanding from reading exception is , might be that specific index not available for search . So trying to unpack this exception more from PIT standpoint :
a. If that specific index is not available for search , why records from that index are returned for PIT on first place ??
b. Is there a way to procced further with pagination search by ignoring this specific index ??
currently its a hard stop there.
Kindly help in understanding more about this exception.