Skip to content

Reverting Error State

By default, if you execute a DELETE request against any entry in ErrorArchive using the deleteEntity() method, it reverts all error states and discards all data from ErrorArchive.

In addition, the requests associated with entries in ErrorArchive are removed.

After the DELETE request, all entities or relationships in error state are reverted so that they appear as though the failed requests were never applied, and are no longer in error state. The ErrorArchive entity set is empty.

DataQuery errorArchiveQuery = new DataQuery().from(errorArchiveSet);

// Get the list of errors in the ErrorArchive
EntityValueList errors = eventService.executeQuery(errorArchiveQuery).getEntityList();
if (errors.size() > 0) {
    eventService.deleteEntity(errors.get(0));
}
let errorArchiveQuery = DataQuery().from(errorArchiveSet)

/// Get the list of errors in ErrorArchive
let errors = try eventService.executeQuery(errorArchiveQuery).entityList()
if errors.length > 0 {
    /// Delete the first error
    try eventService.deleteEntity(errors.first())
}

In case you want to delete individual ErrorArchive entries (in other words, individual failed requests) instead of letting one deletion revert everything, you need to turn this functionality on by calling OfflineODataParameters.setEnableIndividualErrorArchiveDeletion(true)(in Swift source code, setting OfflineODataParameters.enableIndividualErrorArchiveDeletion = true) when opening the offline store with parameters.

With the functionality turned on, deleting an individual failed request from ErrorArchive causes that request and any following requests in the request queue (sent or unsent) that depend on the failed request, to be deleted as well.

It is important that you understand the difference between having the support or not. For example, if the following requests are made by an application, some of which will fail when they are executed on the back end:

  • Request #1: Update event101, which will fail in the back end.
  • Request #2: Update event102, which will fail in the back end.
  • Request #3: Update event101 again.

Now, upload requests #1 to #3. Then, continue to make another request:

  • Request #4: Update event102 again

During the upload, requests #1 and #2 fail due to issues in the back end. Request #3 (the second event101 update) will not be sent to the back end at all because a request it depends on (the first event101 update) failed. At the end of the upload, ErrorArchive has three errors, one for each failed request in the upload.

With the functionality turned off (enableIndividualErrorArchiveDeletion set to false), deleting any entity from ErrorArchive results in requests #1, #2, and #3 being removed from the request queue, but will leave request #4 in the request queue unchanged.

With the functionality turned on (enableIndividualErrorArchiveDeletion set to true), the application decides which failed requests to delete explicitly. There can be different scenarios:

  • If the application chooses to delete failed request #3, it's the only one that's deleted, because no other requests after it in the request queue depend on it.
  • If the application chooses to delete failed request #1, both request #1 and request #3 are removed from the request queue because request #3 depends on request #1.
  • If the application chooses to delete failed request #2, both request #2 and request #4 are deleted because, even though request #4 has not yet been uploaded, it depends on request #2.

Note

The ErrorArchive entity set is offline-specific; there is no need to upload after invoking deleteEntity().


Last update: November 18, 2021