Resuming asynchronous order reindexing on failed documents
Use the _reindexVersion field added in the mappings by default, and the
optional ReindexVersion field in the initiateReindex API input, to
track reindexing progress and resume the operation if an exception occurs.
{
"criteria": [
{
"field" : "OrderDate",
"from" : "2025-05-01",
"to" : "2025-10-08"
}
]
}However, the process fails after updating 70 documents. In this case, 70 documents have
the _reindexVersion updated to 1 but the failed 30 documents does not have any
_reindexVersion value.reindexVersion as shown in the following
sample.{
"criteria": [
{
"field" : "OrderDate",
"from" : "2025-05-01",
"to" : "2025-10-08"
}
],
"reindexVersion" : 1
}This sample input triggers the document reindexing, that has
_reindexVersion with values undefined or less than 1. On successful reindexing, the
reindexVersion of these documents is updated to 1.After multiple reindexing, the documents might have different reindexVersion
values. In such cases, you need to invoke an aggregation query with searchOrder
API for the same reindex criteria first and find the maximum value of the
_reindexVersion amongst the matching orders. You can specify the
reindexVersion with the original criteria and/or filters to reindex the order
documents with reindexVersion value as undefined or lesser than the specified
value.
This query filters the orders that did not reindex in the previous attempt. If the
reindexVersion value is not provided or is set to null, all the order documents
matching the given criteria and/or filters are indexed again. You can also choose to perform a
partial reindex by specifying any valid reindexVersion = n, where
all the documents with value less than n gets picked up for reindexing. Upon
successful reindexing, the reindexVersion of the documents gets updated to
n. In other cases, all the documents that matches the criteria gets picked up and
on successful reindexing, the reindexVersion of the documents is incremented by
1.