Editing attachments of an existing message is broken in v10

[MinnDevelopment]

Description

When you try to add a new file to a message in v10 of the api, using edit message, it removes all existing attachments. This is true, even if you aren't sending an attachments array in the payload at all.

This is a breaking change in v10 that was never explained or documented in the changelog. I don't think this change makes a lot of sense at all, since you are now required to know the entire existing state of the message for edits. As a developer, you gain no benefit from this change, since you could already remove all attachments by just specifying an empty array attachments: [].

Steps to Reproduce

1. Create a message with 1 attachment
2. Edit the message by only sending a multipart request with 1 new file

Expected Behavior

The old behavior from v9, where attachments are only removed when the array is explicitly specified.

Current Behavior

The existing attachment is removed and the new one is added, without the explicit request by the bot.

Screenshots/Videos

No response

Client and System Information

API v10

[mccoderpy]

Can you show us the payload you send?

[MinnDevelopment]

Payload with populated attachments array

--boundary
Content-Disposition: form-data; name="files[0]"; filename="image.png"
Content-Type: application/octet-stream

[image bytes]
--boundary
Content-Disposition: form-data; name="payload_json"
Content-Type: application/json

{"attachments": [{"id" : "994892044541644861"}]}
--boundary--

On v9 and v10, this adds the file and keeps the existing files on the message.

Payload without attachments array

Here, all I'm sending is the file in the multipart body, there is no payload_json at all present. Even if you specify a payload_json, excluding the attachments field, the v10 behavior is different and it treats it identically to attachments: [] either way.

--boundary
Content-Disposition: form-data; name="files[0]"; filename="image.png"
Content-Type: application/octet-stream

[image bytes]
--boundary--

On v9, same behavior as with full attachments array, the new file is added and the existing file stays on the message. On v10, the new file is added, and the existing file is deleted.

[DenverCoder1]

This is not a bug since it was explicitly stated in the version 10 changes

See https://github.com/discord/discord-api-docs/discussions/4510

Existing attachments must be specified when PATCHing messages with new attachments. Any attachments not specified will be removed and replaced with the specified list

[MinnDevelopment]

1. This is not mentioned in the changelog
2. I still don't think this API change is good. There are only negatives.
3. You don't need to specify new attachments in the list either, as I've explained it just adds all files you put in the multipart body regardless.

[DenverCoder1]

There are some reasons to specify attachments in the payload as it's the only way to add the file description / alt text.

But overall, I agree it does have downsides.

[MinnDevelopment]

it's the only way to add the file description / alt text

It really shouldn't be the only way, either. Adding a file with a description shouldn't need to require fetching the message first, just so you can add the files you don't want to edit.

However, the main concern here is really that not specifying the attachments array at all, still behaves as if its now an empty list. In my opinion, omitting it, should be treated as unchanged, how it was in v9.

This change is currently the primary reason why I don't want to update JDA to v10.

[DenverCoder1]

I don't disagree.

I brought up a related issue with it here in regards to editing an interaction response, as it doesn't even return the message when you create it, requiring an extra API call.

For the most part, you can use the response from the endpoint or cached message data to know the existing attachments, but there are exceptions such as older messages that are not cached or interactions as mentioned.

[yonilerner]

Am I correct in understanding that this is really two separate tickets:

• Missing documentation from the changelog
• Feature request to have an alternative way to add an attachment

[yonilerner]

Changelog was updated here: https://github.com/discord/discord-api-docs/pull/5472