You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ignoring exception in on_message_without_command
Traceback (most recent call last):
File "C:\Users\Jakub\OneDrive\Dokumenty\Red-DiscordBot\.venv\lib\site-packages\discord\client.py", line 343, in _run_event
await coro(*args, **kwargs)
File "C:\Users\Jakub\OneDrive\Dokumenty\Sentinel\githubcards\core.py", line 270, in on_message_without_command
await self._query_and_post(message, fetchable_repos)
File "C:\Users\Jakub\OneDrive\Dokumenty\Sentinel\githubcards\core.py", line 309, in _query_and_post
await message.channel.send(embed=embed)
File "C:\Users\Jakub\OneDrive\Dokumenty\Red-DiscordBot\.venv\lib\site-packages\discord\abc.py", line 1065, in send
data = await state.http.send_message(channel.id, content, tts=tts, embed=embed,
File "C:\Users\Jakub\OneDrive\Dokumenty\Red-DiscordBot\.venv\lib\site-packages\discord\http.py", line 254, in request
raise HTTPException(r, data)
discord.errors.HTTPException: 400 Bad Request (error code: 50035): Invalid Form Body
In embed: Embed size exceeds maximum size of 6000
Weirdly enough, the cost of requesting 500 issues is the same as the cost of requesting 1 issue so this can't be leveraged to use huge amounts of rate limit. I was also interested to see whether GitHub won't reject the API request for exceeding payload size or something like that but that didn't seem to happen either. Anyway, I still think we should probably just limit the number of issues we request to something like 50 and ignore all remaining message content. 50 is definitely more than I would expect the person to ever request on a normal basis but I think we should keep some wiggle room rather than put a limit that is too small.
With consideration of message components usage that we wanted to introduce, we could probably limit it to 26 (1 card + the max of 25 select options is what I've seen you test) which still gives wiggle room.
The text was updated successfully, but these errors were encountered:
When you query a lot of issues, the cog might exceed the maximum embed size.
Example reproduction message (
red
is configured toCog-Creators/Red-DiscordBot
repository):Traceback:
I also tried the same with 4k char limit:
Weirdly enough, the cost of requesting 500 issues is the same as the cost of requesting 1 issue so this can't be leveraged to use huge amounts of rate limit. I was also interested to see whether GitHub won't reject the API request for exceeding payload size or something like that but that didn't seem to happen either. Anyway, I still think we should probably just limit the number of issues we request to something like 50 and ignore all remaining message content. 50 is definitely more than I would expect the person to ever request on a normal basis but I think we should keep some wiggle room rather than put a limit that is too small.
With consideration of message components usage that we wanted to introduce, we could probably limit it to 26 (1 card + the max of 25 select options is what I've seen you test) which still gives wiggle room.
The text was updated successfully, but these errors were encountered: