Description

Right now when looking up resources via gRPC calls, every streamed resource includes a continuation token, including the last resource that gets streamed. This confuses the callers of the service because they assume there are more elements to fetch, and therefore they have to make one last call to ensure that no more elements are available in Kessel. Summarizing:

• Assuming there are 1,500 resources in Kessel that want to be fetched.
• * One request is made which makes the Relations API stream 1,000 resources, with the last one having the continuation token "A".
• * Another request is made with continuation token "A", and another 500 resources are streamed. The last resource, in this case, has the continuation token "B".
• * The caller sees that the last element has another continuation token, and since its different to the first one "A", it assumes that there's more to fetch and makes another request with the continuation token "B".
• * Kessel doesn't send any more resources, and the caller now knows that they can stop asking for resources.

The reason why this is a problem is because any caller that makes use of the continuation token will have to implement a similar "stopping mechanism" when fetching resources from the Relations API, because there's no signal like an empty continuation token to stop fetching resources.

Acceptance criteria

• The last streamed element returns an empty continuation token in the last element when there are no more elements left to stream back to the caller.

Please note that having reached the maximum streamable elements per response —currently capped at 1,000 resources— should not make the last element return an empty continuation token if there are more resources that could be streamed in a follow-up call.

More information

A relevant comment left by mmclaugh@redhat.com:
 

A few quick notes for anyone working on this:

1. We should validate that the acceptance criteria, which I think makes sense, is indeed the behaviour of SpiceDB's Cursor, which is currently the underlying implementation of continuation tokens in relations-api. We don't have to copy it blindly, but we should not deviate from it without a reason.
2. Looking at the blame for the code, Abhishek seems to have implemented the feature. I wonder if he did it to support inventory-api? Maybe check your understanding with him in case the behaviour changes unexpectedly and we break something downstream. (Our API contract for continuation tokens is not clear.) 
3. At an absolute minimum, the caller needs a way to determine from a token (or lack of token) whether there are anymore streamable elements available.

Response from SpiceDB in Discord:
https://discord.com/channels/844600078504951838/844600078948630559/1333841251677634631