discord / discord-api-docs

Official Discord API Documentation
https://discord.com/developers/docs/intro
Other
5.91k stars 1.25k forks source link

Message create and edit will give an empty embed if only invalid keys are passed #1361

Closed FasterSpeeding closed 3 years ago

FasterSpeeding commented 4 years ago

When making requests to POST /channels/{channel.id}/messages and PATCH /channels/{channel.id}/messages/{message.id}, if I were to pass an embed that only contains invalid fields with no other fields being passed to create message or edit message while targeting a message that only contains an embed, the expected behaviour would be for it to return a 400 response with the error message Cannot send an empty message (as would be consistent with how this would handle an embed set to null or {} on create or just null on edit). However, the actual behaviour of these endpoints seems to deviate from this with the following requests being examples of when the API allows the creation of messages that only contain empty embeds (seemingly as an oversight has lead to it checking if the embed object is empty before validating the fields in it).

> PATCH /api/v7/channels/561885234413699082/messages/677527952325476372 HTTP/1.1
> Host: discordapp.com
> User-Agent: insomnia/7.0.6
> Content-Type: application/json
> Authorization: Bot ...
> Accept: */*
> Content-Length: 44

| {"content": null, "embed": {"neko": "Hmph"}}

* upload completely sent off: 44 out of 44 bytes

< HTTP/1.1 200 OK
< Date: Thu, 13 Feb 2020 14:54:55 GMT
> POST /api/v7/channels/561885234413699082/messages HTTP/1.1
> Host: discordapp.com
> User-Agent: insomnia/7.0.6
> Content-Type: application/json
> Authorization: Bot ...
> Accept: */*
> Content-Length: 48

| {"embed": {"nyaa i'm not a valid field": "owo"}}

* upload completely sent off: 48 out of 48 bytes

< HTTP/1.1 200 OK
< Date: Thu, 13 Feb 2020 14:54:16 GMT

Both of these requests lead to the messages with empty embeds shown below.

Image of messages

Notes:

night commented 3 years ago

this will be fixed in the next api deploy