Description -
All objCode/search queries support $$FIRST and $$LIMIT parameters for pagination. However, these fail to account properly for lastUpdateDate_Sort=asc where an object may be updated DURING the execution of a scenario, hence the order of entries can be changed in between each separate page query.
Example:
Project 1 - lastUpdateDate=1
Project 2 - lastUpdateDate=2
Project 3 - lastUpdateDate=3
Project 4 - lastUpdateDate=4
Make a query for $$FIRST=0 $$LIMIT=2 and we get:
Project 1 - lastUpdateDate=1
Project 2 - lastUpdateDate=2
Then, asynchronously, let's assume that Project 2 gets updated:
Project 2 - lastUpdateDate=5
Now increment the $$FIRST counter based on the prior $$LIMIT and make a query for $$FIRST=2 $$LIMIT=2 and we get:
Project 4 - lastUpdateDate=4
Project 2 - lastUpdateDate=5
This means Project 3 has effectively been "dropped" from the pagination.
It means we have no guaranteed way to ensure that long-running processes with paginated queries will hit all of the needed objects.
A better pagination mechanism is needed to allow for walking through the individual pages of data from a search, such as using a "cursor" that ensures the next page is retrieved without allowing such a sort drop to occur. You can read more about this problem and suggested solutions at https://jsonapi.org/profiles/ethanresnick/cursor-pagination.
Why is this feature important to you -
We have scenarios that loop through dozens and dozens of pages of responses and need to ensure that update and delete operations that are occurring through the normal course of Workfront being used don't cause "skips" in processing.
How would you like the feature to work -
The objCode/search response should return a cursor entry that replaces the $$FIRST and $$LIMIT parameters and allows for "walking" through the various pages of data in this consistent manner.
Current Behaviour -
See the Description above.
