Closed ghost closed 4 years ago
This would also be an opportunity to provide more informative feedback in these errors, such as replying with the fields expected to be present, etc.
I believe one of our goals in the v7 API is to improve error responses from our API in general, so this concept is one we're generally aware of and planning to improve.
I can't personally speak to these error...errors (lol) but I'll go ask some folks tomorrow (if they don't beat me to it here).
Cool, ill be interested to hear any info, thanks
Invoking POST /guilds returns a 50035 Invalid Form Body despite the input being a JSON-encoded body, and not a form-encoded body, which is somewhat misleading.
The encoding of the content is unrelated to the error message, Invalid Form Body
. The word "form" in this case is actually referring to the generic form/schema of data you must fill out. Forms have validation, so this is a form validation error.
These errors are also specific to API v7+, which we have not documented and do not officially support usage of.
Ideally, validation errors such as this should be represented in a single generic way that is consistent for all endpoints, such as the format defined in RFC-7807 Section 3 regarding using the RFC-7801 Problem Details response to represent validation failures, which has somewhat been emulated in the first response but in an undocumented format that is not supposed to be used externally it would appear.
This would also be an opportunity to provide more informative feedback in these errors, such as replying with the fields expected to be present, etc.
This is how API v7+ errors function already for the most part (although it is not perfect and never will be because data you provide could change requirements or validation dynamically). We return all the errors in the schema by which the request was sent. Missing required fields are noted in the response. Specifically for your example, we tell you the name
field has a BASE_TYPE_REQUIRED
error. This code implies that name is required in the request.
Hello. I'm using browser version of Discord and get the same error
{"code": 50035, "errors": {"application_ids": {"_errors": [{"code": "BASE_TYPE_REQUIRED", "message": "This field is required"}]}}, "message": "Invalid Form Body"}
I can't using voice chats, watching streams, I don't hear anyone.
I'm using chrome 100.0.4896.60 x64 Windows 11
That error has nothing todo with you not hearing any audio, all clients atm fetch that endpoint and don't provide an app id resulting in that error, but this repo isn't for client issues, you'll have to go to discords support site for those.
im trying to programmatically click a button in discord and i am seeing this error. anyone know what could be amiss here:
headers = { 'authorization' : self.token}
data = {
"type": 3,
"guild_id": msg.guild_id,
"channel_id": msg.channel_id,
"message_id": msg.id,
#"application_id": "XXX",
"data": {
"component_type": 2,
"custom_id": button_id
}
}
requests.post('https://discord.com/api/v9/interactions', json=data, headers = headers)
that doesn't seem to have anything to do with this 2020 issue, and automating interactions is not allowed (as it requires using a user token which isn't allowed).
and automating interactions is not allowed (as it requires using a user token which isn't allowed).
i was getting the same error messages. and what do u mean it's not allowed..the dev portal has examples pertaining to interactions - it's supported by the interaction api. anyway, i was able to get this to work. would prefer if i could get it working w/ websockets and asyncio though - that seems problematic
Invoking
POST /guilds
returns a 50035 Invalid Form Body despite the input being a JSON-encoded body, and not a form-encoded body, which is somewhat misleading.If this is not a bug on this specific endpoint,(edit: verified this is the case on other endpoints too) this probably should be split into a code for JSON parsing errors, a code for form-encoding errors, a code for missing required fields, etc.Currently, creating a guild without the
name
key returns the following response:However, creating a message without any "content" key:
Ideally, validation errors such as this should be represented in a single generic way that is consistent for all endpoints, such as the format defined in RFC-7807 Section 3 regarding using the RFC-7801 Problem Details response to represent validation failures, which has somewhat been emulated in the first response but in an undocumented format that is not supposed to be used externally it would appear.
This would also be an opportunity to provide more informative feedback in these errors, such as replying with the fields expected to be present, etc.