Why is `endCursor` nilable if there's also a `hasNextPage` boolean?

[amomchilov]

trafficstars

Not really an issue/bug, but I'm just trying to gather some context.

In my code, I had an assertion like so:

if page_info.fetch("hasNextPage") == page_info.fetch("endCursor").nil?
  raise "If 'hasNextPage' is true, then the cursor 'endCursor' must be non-nil!"
end

I figured that hasNextPage: true should imply endCusor: nil, and vice-versa, but that's not the case for ArrayConnection.

I'll just remove this assertion, but I'm curious: what's the purpose of hasNextPage? Couldn't clients imply there's no next page, simply from seeing the endCursor is nil?

[rmosolgo]

Well... went to look up the Relay server spec, and I found that these cursors are actually supposed to be null: false: https://relay.dev/graphql/connections.htm#sec-undefined.PageInfo.Introspection

Maybe that answers the question: endCursor is always supposed to have a value, but hasNextPage will tell you whether or not to expect more items in the list.

I think GraphQL-Ruby's PageInfo type should be fixed, but I'll have to double-check the history on that; maybe there's some reason it's defined that way 🤔

[myronmarston]

Well... went to look up the Relay server spec, and I found that these cursors are actually supposed to be null: false: https://relay.dev/graphql/connections.htm#sec-undefined.PageInfo.Introspection

Maybe that answers the question: endCursor is always supposed to have a value, but hasNextPage will tell you whether or not to expect more items in the list.

I think it's actually a bug in the relay spec, as you discussed in this previous conversation:

https://github.com/rmosolgo/graphql-ruby/pull/2886#issuecomment-618414736

endCursor needs to be nilable for the case where the connection has an empty list of edges.

[amomchilov]

Interesting find. Thanks for the context!

[rmosolgo]

Thanks for sharing that, @myronmarston -- I guess that answers it 🍻