The pagination cursor returned by the new unban_requests API seems wrong

[SylvainSimon]

Hi,

It’s been a long time since I posted a topic 😃
Feedback from the new API in beta GET helix/moderation/unban_requests

I have been using it since it was made available in the following way: I created an interface which allows me to process each deban request for a streamer, in a slightly more role play way. It’s a kind of court that will allow the streamer to judge each ban call by providing him with the information we have on the user (messages, previous timeouts, whatchtime, etc.)

In this context I use this last API by providing it, at the beginning only with the field first = 1/status = pending, to have one case at a time.

When we move on to the next case, I use the pagination cursor to provide it to the query. So I send the same API call as previous but with after = previous cursor.

It works very well, let’s say at the beginning… after a while, and I noticed from 30 cases, without the delay having anything to do with it, the API starts to send me empty data, while continuing to give me cursors…

While I continue to provide it and I make the calls… and after a moment, magically, I have the following recording (which is indeed the one which should have been given to me from the start).

In the same way when I theoretically arrive at the last deban request in pending status (around forty, easy to check with the call without first parameter), the API continues to send me cursors for the next pagination…

My theory is that there is a bug which means that the pagination does not apply to the data filtered by the status but continues as if there was none, but that when I send the data back of the recording, so having filtered everything that is not pending, there is nothing left in the response body.

Step to reproduce :

• Have many unban requests on channel.
• Fetch GET helix/moderation/unban_requests for pending status and first = 1
• Follow cursor many times until you got empty data... (my case i used to follow ~30) but i think its relative to potentially previsouly resolved unban request or just in another statut in this call (like if it was called without status filter)

[SylvainSimon]

Update i reproduce with first = 2, lot of time i got 2 result in data, screenshot in orders for exemple

First call 2 results, and pagination

I follow the cursor many time (10/20) with always first = 2, and suddenly, no result

I follow the cursor anyway... 1 result...

One more time, 1 result

And the next time... 2 result..

The next call normally give me the LAST unban request in pending status for this channel, so i got one result, But why i'v a pagination field ???

All calls after this give me 0 result and continue to give a pagination cursor..

[SylvainSimon]

For your information, the call in totally basic and i don't change anything except the "after", empty the first time and filled by the previous cursor each call

[SylvainSimon]

More and last exemple, if i send the first = 100, i got the GOOD numbers of unban request in pending state

And this time, no pagination, normal.

If i ask for... 20 per 20, here we go again... First time, 20, normal

Next time with the cursor... 18 ????? Ok ??

Next... 7

And after.. nothing... BUT, with pagination ahahah

Hypothesis therefore: As soon as we put an "after" parameter the pagination is completely lost and stalls as if we had unfiltered results... or in another status, in any case not correlated with the query..

So I imagine that if I had more than 100 requests on the channel, I would be completely unable to loop to retrieve them all because page 2 would show me random results count and pagination cursor...

[SylvainSimon]

No one cares about this ?