Missing retry_after parameter in rate limits

[Luc1412]

Summary

Context:
I got a bot that broadcast messages (Game updates) to multiple thousand servers (who subscribed to it). I try to do this task as fast as possible. Normally I post it with multiple threads and discord.py auto handles the rate limits for me.

It seems that since 01/26 it sometimes happens that the retry_after parameter isn't included?
This only happens after approx. 4min of posting at max speed.

Reproduction Steps

I'm not sure. I think sending messages at max speed.

Expected Results

The API auto handles the missing retry_after parameter and might do a default timeout.

Actual Results

An error gets thrown:

    message = await channel.fetch_message(int(message_data['message_id']))
  File "/opt/EasyFortniteStats/bot_venv/lib/python3.8/site-packages/discord/abc.py", line 921, in fetch_message
    data = await self._state.http.get_message(channel.id, id)
  File "/opt/EasyFortniteStats/bot_venv/lib/python3.8/site-packages/discord/http.py", line 189, in request
    retry_after = data['retry_after'] / 1000.0
KeyError: 'retry_after'
NoneType: None

Checklist

• I have searched the open issues for duplicates.
• I have shown the entire traceback, if possible.
• I have removed my token from display, if visible.

System Information

• Python v3.8.0-final
• discord.py v1.3.1-final
• aiohttp v3.5.4
• websockets v6.0
• system info: Linux 4.9.0-11-amd64 Fix issue with author changing type #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11)

[Rapptz]

I can't reproduce this.

Also I'm unsure why you're using multiple threads since this stuff isn't thread safe -- which might actually invalidate this bug report.

If you have DEBUG logging enabled to see the raw API response it'd be more helpful but right now I'm not sure this is even possible since that's a wide scope of breakage at the API layer.

[Luc1412]

Also I'm unsure why you're using multiple threads since this stuff isn't thread safe -- which might actually invalidate this bug report.

My current code looks simplified like this:

recipients = [gid1, gid2, gid3, gid4]  # List of guild ids
recipients_chunks = someCustomMethodToChunk(recipients, 2)  # Create sublists with the defined number of entries eg. [[gid1, gid2], [gid3, gid4]]

broadcast_tasks = []
for recipients_chunks in recipients_chunks:
    broadcast_tasks.append(self.bot.loop.create_task(self.bc_chunk(premium_guild_chunk)))
for broadcast_task in broadcast_tasks:
    result = broadcast_task.result()
    # doing stuff with the result
print('finished')

async def _broadcast_chunk(self, chunk_recipients):
    for recipients in chunk_recipients:
        # doing some stuff and getting channel id from db
        await channel.send('My Message')

Is this wrong?

If you have DEBUG logging enabled to see the raw API response it'd be more helpful but right now I'm not sure this is even possible since that's a wide scope of breakage at the API layer.

For today's broadcast, I enable DEBUG to get more details.

[Rapptz]

It turns out that this is received when you do something that causes around 5000 429s in a short time frame from our testing in the d.py server. Cloudflare bans you for an hour with a message like this:

{
  "code": 0,
  "message": "You are being blocked from accessing our API temporarily due to exceeding our rate limits frequently. Please read our docs at https://discordapp.com/developers/docs/topics/rate-limits to prevent this moving forward."
}

A commit, 25a04ed, addressed this earlier. However, I'm unsure how you managed to get that many 429s since the library handles it. In order to reproduce it we had to not use the library but rather a new HTTP session with no 429 handling whatsoever.