[Bug] Moderation API for Banned Users is bugged

I found a severe bug on the moderation API endpoint: https://api.twitch.tv/helix/moderation/banned

First the docs do not mention the first field in the query params but it works. The first query params determines how many results you wish to query. This is not mentioned in the docs for the API but it works.

On to the topic:
Bug is that there is a cap on the total results that you get dependant on the amount you put into the first query param.

The formula for the total result is:
total = 100000/X
whereas X is the number of results you wish to query for.

I use JS and the request module to make the API calls this is the main request object I create:

  request({
    baseUrl: 'https://api.twitch.tv/helix/',
    url: 'moderation/banned',
    qs: {
      broadcaster_id: channel_id,
      after: after,
      first: _first
    },
    headers: {
      'Authorization': `Bearer ${access_token}`
    },
    json: true
  }, (err, res, body) => {...});

There is of course some additional logic around it I just show the query I do and that it should work perfectly.

-> The API returns { error: 'Internal Server Error', status: 500, message: '' } when the total result amount is reached, this is what fails and what is the main bug here

I will now present some numbers about how many total results I get depending on the amount I put in first. The query is done for a big channel with lots of banned people

The first column is the amount I plugged into the first query string param
The second column is the total results that I got in the end using forward pagination when the API reports me that internal error.

users/request ..................... total
100                                  1.000
75                                   1.333
50                                   2.000
30                                   3.333
20                                   5.000
10                                  10.000
5                                   20.000
4                                   25.000
3                                   33.333

The API seems to be bugged to me and it depends on the amount of users that one wants per request how many results you are allowed to get in the end. The max cap seems to be 100k as if you follow the formula this should be the max results you can have.

I am running a script at the moment which reduces the number of users per requests by one on every consecutive fail taking the last working cursor before the one that gave me the server error and I am at the moment at 2 Users per request and 40k results.

I didnt check if I get any double user names in the process but I will do that ones I reach 100k in 2 hours starting it again from the beginning.

In conclusion: that API seems bugged to me as it caps the max results depending on an arbitrary value that you send in the query params.

Also I doubt the amount of timed out people and the total amount of banned people a bit. On that channel I know for sure that approx. 300 - 400 people get banned monthly but having 40k now already is a bit too much for 3 years streaming I think, so maybe the cursors are broken, I dont know. My stopping condition of requesting more results is getting less than the amount of results I want that was put into first.

I don’t know if some Twitch dev will read it but I hope this gets resolved and also the docs should be cleaned up, there are missing query params in the docs and also errors in the description like:

https://dev.twitch.tv/docs/api/reference/#get-banned-users

and

https://dev.twitch.tv/docs/api/reference/#get-moderators

Both have the same Descriptions. There should be some work done about these issues asap imo.

EDIT:
It turns out the cursors I am getting for forward pagination seem to be wrong.

Here is a table with the max amount of unique users that I get using different values for the first parameter

users/request ............. unique Users
100                                  200
75                                   150
50                                   150
40                                   160
30                                   150
20                                   200
10                                   360
5                                    705
3                                  1.170

Another Test run where Users is the first value and Total is the unique results I got:

Users: 100 Total: 200
Users:  95 Total: 190
Users:  90 Total: 180
Users:  85 Total: 170
Users:  80 Total: 160
Users:  75 Total: 150
Users:  70 Total: 140
Users:  65 Total: 130
Users:  60 Total: 120
Users:  55 Total: 165
Users:  50 Total: 150
Users:  45 Total: 135
Users:  40 Total: 160
Users:  35 Total: 140
Users:  30 Total: 150
Users:  25 Total: 175
Users:  20 Total: 200
Users:  15 Total: 255
Users:  10 Total: 360
Users:   5 Total: 705

If someone wants to test it out, but doesnt have an auth token from a bigger channel and is a trustworthy member here I would be willing to share the Auth token and channel id in private message. It should be done on a trust basis of course as the token is able to read the email of the broadcaster and has of course the moderation:read scope. I would lend that auth token for some testing to confirm that there is indeed a bug and then invalidate it when you confirm in your tests that its bugged. I would really like to have this resolved as soon as possible.

Never share auth tokens, that’s a significant violation of the Developer Agreement, and if the token also allows access to an email address then that may be a big privacy issue too resulting in legal repercussions.

Ok I won’t, but I hope it will get resolved anyways. There is something broken for sure on that API.

Using:

const fs = require('fs');
const path = require('path');

const got = require('got');

var users = {};
let page = 0;
fetchPage = function(c) {
    got({
        url: 'https://api.twitch.tv/helix/moderation/banned',
        searchParams: {
            broadcaster_id: 'A BIG STREAMER',
            after: c,
            first: 100
        },
        headers: {
            authorization: 'Bearer REDACTED'
        },
        responseType: 'json'
    })
    .then(resp => {
        page++;

        for (var x=0;x<resp.body.data.length;x++) {
            users[resp.body.data[x].user_id] = 1;
        }

        console.log('Page',page,'has',resp.body.data.length,'users',Object.keys(users).length);

        fs.appendFileSync(path.join(
            __dirname,
            'pages',
            page + '.json'
        ), JSON.stringify(resp.body,null,4));
        if (resp.body.pagination && resp.body.pagination.cursor) {
            fetchPage(resp.body.pagination.cursor);
        }
    })
    .catch(err => {
        console.log(err);
    });
}
fetchPage('');

I got the first 10 pages and the 11th crashed

Page 1 has 100 users 100
Page 2 has 100 users 200
Page 3 has 100 users 200
Page 4 has 100 users 200
Page 5 has 100 users 200
Page 6 has 100 users 200
Page 7 has 100 users 200
Page 8 has 100 users 200
Page 9 has 100 users 200
Page 10 has 100 users 200
{ HTTPError: Response code 500 (Internal Server Error)
    at EventEmitter.emitter.on (/REDACTED/misc/node_modules/got/dist/source/as-promise.js:109:31)
    at process._tickCallback (internal/process/next_tick.js:68:7) code: undefined, name: 'HTTPError' }

But every page 2 thru 10 were the same.

I don’t use this API to go fetch all the users that are banned, which is why I’ve not noticed this. I use the 1 2 1 look up for specific users and thats working fine/as expected.

For what purpose are you after the whole list for out of interest?

Looks correct?

@Elias_Kechter Thanks for the reporting the issue you’ve seen with the Moderation API. We just recently began tracking and delivering bug reports through https://github.com/twitchdev/issues.

Could you move this report to a GitHub issues on the repository? I would suggest one for the API error and one for the doc update since these are different teams. We can then route the issue to the right folks. Thanks again for providing the detail to help us resolve the issues.

I already put it on Github @jbulava

And

1 Like

Awesome, seeing that now and thanks for linking here.

Please add any further thoughts or comments on these GitHub issues.