According to documentation, even when a paginationToken is provided in the query, the query must still contain the request body that was submitted in the previous query that generated the paginationToken.
However, the startDate cannot go back farther than 30 days in sandbox and 180 days in production.
If the maximum 180 days is used in the startDate that generated the paginationToken, then in any subsequent query, if the same startDate is used, then it would in fact exceed the maximum allowed history duration.
This is in fact tested to be the case. In subsequent queries, using the paginationToken and its startDate, a JSON StartDateTooFarInPastError error was thrown.
However, at the same time, it is not true that the request body, including startDate, has to be exactly the same as the request body of the query that generated the paginationToken. If startDate is increased so little, just enough to satisfy the maximum allowed, the query seems to return the correct results.
However, if the startDate is changed drastically, then it throws PaginationTokenExpiredError error.
How do I handle this edge case where the documentation says that you must provide the same request body of the query that generated the paginationToken while at the same time ensuring that startDate is now in subsequent queries don’t fail the StartDateTooFarInPastError requirement?
