As reported by @rudigiesler : In the spec right now, Row IDs can be strings or integers. While individual systems are likely to use one or the other, a Flow Results server would need to accept both. This means that you could have rows with id=1 and also id="1".
For pagination by Row ID, we need a unique ordering (ie: ?page[afterCursor]=1). Therefore, the spec should specify that Row IDs must be unique within the package, and that Row IDs will be compared as strings.
There was one issue with the spec that I ran into when implementing. In the spec, it's mentioned that a row_id can be either an integer or a string, and that it's unique across all responses for a package/flow. This means that you could have one response with an ID of 1, an integer, and one response with an ID of "1", a string, and that's fine because they're not equal. But when paginating, we use the page[afterCursor], and page[beforeCursor] query params, where the cursor here is a row_id. But with querystrings, the values are all strings, we cannot tell the difference between an integer and a string. So in this implementation, if the query param could be an integer, we look for a row_id of either an integer or a string. The issue here is, if I do a ?page[afterCursor]=1, then it will match both of the responses in my example. At the moment we just log an error, and return a 500 server error, because I'm not sure what to do in this case, and the spec documentation doesn't mention this either.
As reported by @rudigiesler : In the spec right now, Row IDs can be strings or integers. While individual systems are likely to use one or the other, a Flow Results server would need to accept both. This means that you could have rows with
id=1and alsoid="1".For pagination by Row ID, we need a unique ordering (ie:
?page[afterCursor]=1). Therefore, the spec should specify that Row IDs must be unique within the package, and that Row IDs will be compared as strings.