You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
We just had a production incident in part because we retrieved the first page of a list, assumed there were no more pages and ended up returning a subset of the available resources. That's an easy mistake to make based on the design, which returns you the results and the NextToken side by side, e.g.
typeListFunctionDefinitionVersionsOutputstruct {
NextToken*string`type:"string"`Versions []*VersionInformation`type:"list"`// contains filtered or unexported fields
}
It would be nice if there was a pagination design that made it harder to skip past the second, third, fourth page of resources. For example, borrow from the rows.Next() implementation in database/sql or bufio.Scanner. Or here is how I roughly implemented this in my twilio-go library.
Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.
Hi,
We just had a production incident in part because we retrieved the first page of a list, assumed there were no more pages and ended up returning a subset of the available resources. That's an easy mistake to make based on the design, which returns you the results and the NextToken side by side, e.g.
It would be nice if there was a pagination design that made it harder to skip past the second, third, fourth page of resources. For example, borrow from the
rows.Next()
implementation in database/sql or bufio.Scanner. Or here is how I roughly implemented this in my twilio-go library.It's a lot harder to accidentally forget to page that way.
The text was updated successfully, but these errors were encountered: