Invalid cursors

[facebook]

Invalid cursors

[dschafer]

The behavior right now is unspecified, and the behavior might vary on a connection-by-connection basis. For some connections it might appear to work, though the results are probably unexpected. An object’s ID often makes a nice cursor, but if we do that, the cursors are the same no matter what ordering we use; similarly, if we're using offsets as cursors, the cursors are the same for every ordering. Other connections throw a specific error that the client will recognize that says “that cursor is not valid” (we do that for news feed, for example; feed on the homepage doesn’t go back infinitely, so if you have an old enough cache, the cursor might not be valid on the server anymore).

We might be able to clarify the spec by adding some may language here; a server may encode information in the cursor that identifies the other arguments passed to the connection; if it does so and sees a cursor used with different arguments, it may throw an error indicating the issue to the client. That's a nice suggested behavior for cases where it makes sense to use more complex cursors, while still allowing the "ID as cursor" and "offset as cursor" cases to be valid in the spec.

Let me know what you think of that language, and I can update the spec?

[freiksenet]

Yeah, this change sounds good! I am still undecided myself on that issue, so it's good to have permissive language on that in the spec. 

Thank you!

On Wed, Aug 12, 2015 at 9:50 PM, Dan Schafer [email protected]
wrote:

The behavior right now is unspecified, and the behavior might vary on a connection-by-connection basis. For some connections it might appear to work, though the results are probably unexpected. An object’s ID often makes a nice cursor, but if we do that, the cursors are the same no matter what ordering we use; similarly, if we're using offsets as cursors, the cursors are the same for every ordering. Other connections throw a specific error that the client will recognize that says “that cursor is not valid” (we do that for news feed, for example; feed on the homepage doesn’t go back infinitely, so if you have an old enough cache, the cursor might not be valid on the server anymore).
We might be able to clarify the spec by adding some may language here; a server may encode information in the cursor that identifies the other arguments passed to the connection; if it does so and sees a cursor used with different arguments, it may throw an error indicating the issue to the client. That's a nice suggested behavior for cases where it makes sense to use more complex cursors, while still allowing the "ID as cursor" and "offset as cursor" cases to be valid in the spec.

Let me know what you think of that language, and I can update the spec?

Reply to this email directly or view it on GitHub:
#32 (comment)

[jardakotesovec]

Do I understand correctly that currently there is no mechanism to invalidate cursors (and start over) on the client if I change arguments on connection?

[freiksenet]

If you change the arguments then you will get new cursors for this arguments, old cursors would still be valid for old arguments. Why would you want to invalidate them?

[jardakotesovec]

@freiksenet Right, In that case I apparently don't understand correctly what is the actual issue you reported.

mentioned that using cursors when, eg, ordering changes is not guaranteed to be correct.

I thought that you are referring of changing connection argument (orderby) is causing the problem with cursors. Maybe if you could give me example with bit more context.

Thanks!

[freiksenet]

If you change some of the arguments like orderBy, cursors might not be valid for those new arguments, so server might want to signal an error. Those cursors are still valid for old connection arguments. My question was just whether server should signal error.

[jardakotesovec]

Quoting @yuzhi from slack

You can have something like connectionName(orderby: 'foo', first: 10), Relay will keep it > separate from connectionName(first:10), and do it's best to keep the ordering we got from the server.

@freiksenet So as you also mentioned - Relay use new cursors with new arguments for connection.

I understand @dschafer example - when cursors on server changes for some reason (cache expires, data changes by different client, ...) it makes sense to inform client that existing cursors are invalid.

But still don't understand why changing connection arguments on client would cause the problem as Relay should keep separate cursors automatically.

Hope I am not causing more confusion.. but its important for me to understand what limitations are potentially there. Thanks!

[freiksenet]

I am talking about server-side behavior, not client-side. It's good that Relay handles it, but I need to know how our server should handle it too for clients different than Relay. This repository includes spec for GraphQL servers, that's why I am raising the issue here :)

[jardakotesovec]

Ok, now its clear. Thanks.

[yungsters]

Looks like all questions have been answered. If that is not the case, I apologize and please feel free to re-open.