Invalid nextToken type in generated schema with @searchable

Describe the bug In generated schema for models that has @searchable attribute there are generated search* methods with invalid nextToken type - Int. These methods returns nextToken as Long (encoded as String) so one cannot continue searching with this token because of following error returned from GraphQL API endpoint:

{
  "message": "Variable 'nextToken' has an invalid value. Expected type 'Int' but was 'Long'."
}

To Reproduce Steps to reproduce the behavior:

1. Generate schema using amplify push for model:

type Customer
    @model(mutations: { create: "createCustomer", update: "updateCustomer" })
    @searchable
    @auth(rules: [
        { allow: groups, groups: ["Administrators"] },
    ]) {
    data: AWSJSON
    isArchived: Boolean!
    createdAt: AWSDateTime
    id: ID!
    name: String!
    address: String
    description: String
    phone: String
    email: String
}

1. In generated schema we have:

	searchCustomers(
		filter: SearchableCustomerFilterInput,
		sort: SearchableCustomerSortInput,
		limit: Int,
		nextToken: Int
	): SearchableCustomerConnection

1. Try to search using this method with some low limit to get results & nextToken:

{
  "searchCustomers": {
    "__typename": "SearchableCustomerConnection",
    "items": [ ... ],
    "nextToken": "1547964054859"
  }
}

1. Try use generated value (ex. 1547964054859) in next search as nextToken:

{
  "message": "Variable 'nextToken' has an invalid value. Expected type 'Int' but was 'Long'."
}

Expected behavior Something is wrong with generated schema AND typescript (I’m using Angular) code. Search* method returns very long number in response as a string but expects Int in next call.

[johnf]

I did hours of research on this today. I think the implementation is incorrect. The code is assuming that search works the same way as list and that the entry in sort can be used as a nextToken.

That is how DynamoDB backend works, but not how the ElasticSearch backend works. ElasticSearch implements from and it should be an offset. i.e. if you want the 11-20th records you would set from to 11. Similar to SQL OFFSET

I think nextToken should be renamed to offset or from for a search and the code trying to add nextToken to the response should be removed.

Could be wrong, but hust using ```{ limit: pageSize, nextToken: page*pageSize } works for me, and also makes sense that it is an int.

The above isn’t a great description but I’m in a rush at the moment. If it’s not clear I can provide more detail later

[github-actions[bot]]

This issue has been automatically locked since there hasn’t been any recent activity after it was closed. Please open a new issue for related bugs.

Looking for a help forum? We recommend joining the Amplify Community Discord server *-help channels or Discussions for those types of questions.