While implementation I found out the indexed content post purge not only delete indexed content but the underlying content type schema too. i.e. the elastic storage container. Thus if we again index content if fails to index content. Though it gives success response with journal id, internally the Optimizely graph do not index content and gives exceptions index not found.

Which led me to opening a ticket with optimizely support explaining them the issue https://support.optimizely.com/hc/en-us/requests/1908585

The response from opti support team about no index found exception post purge is following:

Thank you for waiting. I tested with my production CG instance and observed the same issue as you.
Our development team has responded:
Endpoint DELETE /api/content/v2/data is a legacy API, we never changed its behavior to avoid breaking change.
The DELETE /api/content/v3/sources?mode=data will delete ALL data including the indices.
DELETE /api/content/v3/sources?mode=reset will delete all data including indices except the index for standard locale, so even the index for en locale will be deleted, so you will still get indexnotfound error when trying to index a document to en-US.
We think the only way to resolve this is to call the API to recreate the schema, and then call the API again to index the documents.

The ask is, the purge must just only remove content and not underlying schema i.e. content type.