NS_ERROR_STORAGE_ERROR during Places pagination with mozIStorageResultSet

When paginating large bookmark or history datasets through Firefox's Places SQLite API, a mozIStorageResultSet is typically obtained via mozIStorageConnection.executeQuery() and walked page by page with LIMIT and OFFSET. The API does not guarantee stable ordering unless an explicit ORDER BY clause is present, so concurrent writes to the database between page fetches can shift the result window and produce duplicate or missing rows.

A separate failure condition arises during asynchronous pagination if the mozIStorageConnection is released before the result set is fully consumed. Accessing the result set afterward raises NS_ERROR_STORAGE_ERROR (0x80040100). The implementation does not appear to automatically retry or reset the cursor, and the public MDN documentation for mozIStorageResultSet does not clearly state whether the caller must re-execute the query and rebuild pagination state from scratch.

Given these constraints, what is the supported recovery pattern for NS_ERROR_STORAGE_ERROR in a long-running pagination loop? Should a deterministic sort column be treated as mandatory for correctness, or is the non-deterministic behavior considered acceptable for read-only snapshots? Is there a documented mechanism to revalidate an existing result set after the underlying connection has been closed, or is re-execution the only supported path?