Skip to content

Improve handling of pagination parameters on campaigns connections

Created by: eseliger

Currently, -1 has internally a different meaning than none, but unlimited. -2 however, probably causes a DB error, limit -2. I think we should not allow values < 0. Thinking about it, it feels like it also makes sense to remove the "magic", undocumented default list limit. It's caused us internally a lot of pain because it was forgotten, and consumers of the API can also not know about it, since it's undocumented behavior. So I'd opt for removing the magic default limit, but rather add a maximum allowed in the graphql layer First param provided, also to avoid overload.

Work items

  • Introduce validation for first >= 0
  • Refactor store methods to not have magical defaultLimit, but Limit: 0 => LIMIT ALL
  • Think about upper boundary for list resolvers
  • Make ConnectionArgs helper compatible with non-pointers not needed
  • Find a way to make the changesets list page through results, currently can't because we reload the whole packet Currently we'll just allow large pages for changesets, will revisit once we have fixed page frames or so.