This is a v10 bug.
If you take the after cursor from CollectionName.all().paginate(1), and then use it in Set.paginate(after, 1), then the Set.paginate call will return the original cursor and will not allow you to advance in the set.
I experienced this bug using the latest docker (fauna/faunadb:5.9.0) and the vscode FQLPlayground
I could not replicate on the public RGs.
Nor against the latest docker image
I did however, have a bear of a time getting my terminal to understand what I was trying to copy/paste and thought I was changing the cursor, but turns out I just kept pasting in the same original cursor.
If you double check things and are sure you have a legitimate case, then please try to replicate from scratch and let us know what steps to take to replicate.
.pageSize vs .paginateFor those that have been around a while, some_set.paginate() has been the only way to specify a page size. Unfortunately, however, this has always meant a return type of Object (a page object with data and optional after fields).
With the new .pageSize, the return type is a proper Set, which means the result is sent over the wire encoded as such (wrapped in an object with a @set field if one were to go looking).
(we should have <Set>.pageSize up in documentation soon)
The important point is that drivers can deserialize an encoded Set and safely use it with pagination helpers. For example, the following will now work in javascript
const iter = client.paginate(fql`CollectionName.all().pageSize(1)`)
for await (const page of iter) { /* ... */ }
Whereas this does not work, because the result of the query is an object instead of an encoded Set.
const iter = client.paginate(fql`CollectionName.all().paginate(1)`)
In either case, you follow up with subsequent pages using Set.paginate(after), but with the initial query result the drivers can be certain they started working with a real Set.
Thank you for taking the time to reproduce the issue. I’ll go over things again and see if there’s any mistakes I was making.