Cannot use Components V2 if you defer an interaction (you have to use undocumented API)

[TheKodeToad]

Description

Intuitively you would think to use components v2 in a deferred interaction you would need to pass in the flags for the initial defer

I.e. first you would do

POST https://discord.com/api/v10/interactions/{interaction id}/{interaction token}/callback?with_response=true
{"data":{"flags":32768},"type":5} // flags = IS_COMPONENTS_v2, type = DEFERED_CHANNEL_MESSAGE_WITH_SOURCE

then you would think you'd be able to use components freely

PATCH https://discord.com/api/v10/webhooks/{client id}/{token}/messages/@original
{"components":[{"type":10,"content":":x:"}]}

However, instead you have to put the flags in the latter payload - like so

{"components":[{"type":10,"content":":x:"}],"flags":32768}

The documentation does technically tell you this flag won't work here - but the alternative is not documented - and I am not sure whether this is a bug - but in any case the docs do need updating.

Steps to Reproduce

Very strange Discord.JS example - but it should get the idea across

const { Client, Events, REST, Routes } = require("discord.js");

const TOKEN = "your token";
const CLIENT_ID = "your client id";

const commands = [
  {
    name: "ping",
    description: "Replies with Pong!",
  },
];

const rest = new REST({ version: "10" }).setToken(TOKEN);
const client = new Client({ intents: [] });

async function run() {
	await rest.put(Routes.applicationCommands(CLIENT_ID), { body: commands });

	client.login(TOKEN);

	client.on(Events.InteractionCreate, async interaction => {
		if (!interaction.isChatInputCommand())
			return;

		if (interaction.commandName === "ping") {
			await fetch(
				`https://discord.com/api/v10/interactions/${interaction.id}/${interaction.token}/callback?with_response=true`,
				{
					method: "POST",
					headers: { Authentation: "Bot " + TOKEN, "Content-Type": "application/json" },
					body: JSON.stringify({ data: { flags: 32768 }, type: 5 })
				}
			).then(res => res.text()).then(res => console.log("Callback response: " + res));

			await fetch(
				`https://discord.com/api/v10/webhooks/${CLIENT_ID}/${interaction.token}/messages/@original`,
				{
					method: "PATCH",
					headers: { Authentation: "Bot " + TOKEN, "Content-Type": "application/json" },
					body: JSON.stringify({ components: [{ type: 10, "content": ":x:" }] })
				}
			).then(res => res.text()).then(res => console.log("Edit response: " + res));
		}
	});
}

run();

Using undocumented API it works just fine

			await fetch(
				`https://discord.com/api/v10/interactions/${interaction.id}/${interaction.token}/callback?with_response=true`,
				{
					method: "POST",
					headers: { Authentation: "Bot " + TOKEN, "Content-Type": "application/json" },
					body: JSON.stringify({ type: 5 })
				}
			).then(res => res.text()).then(res => console.log("Callback response: " + res));

			await fetch(
				`https://discord.com/api/v10/webhooks/${CLIENT_ID}/${interaction.token}/messages/@original`,
				{
					method: "PATCH",
					headers: { Authentation: "Bot " + TOKEN, "Content-Type": "application/json" },
					body: JSON.stringify({ components: [{ type: 10, "content": ":x:" }], flags: 32768 })
				}
			).then(res => res.text()).then(res => console.log("Edit response: " + res));

Expected Behavior

I would expect the message to be deferred and then update with ❌ displayed as a component. Using flags in the webhook PATCH request feels inconsistent but it wouldn't surprise me if this was intentional (in fact I don't know how this could happen accidentally lol) - if the behaviour is kept the docs should simply be updated.

Current Behavior

This is returned when trying to edit

{
  "message": "Invalid Form Body",
  "code": 50035,
  "errors": {
    "components": {
      "0": {
        "_errors": [
          {
            "code": "UNION_TYPE_CHOICES",
            "message": "Value of field \"type\" must be one of (1,)."
          }
        ]
      }
    }
  }
}

Screenshots/Videos

No response

Client and System Information

N/A

[PakjeBecel]

DOCS | Interactions - Receiving and Responding: Interaction Response Object

flags? * | integer | Message flags combined as a bitfield (only SUPPRESS_EMBEDS, EPHEMERAL, and SUPPRESS_NOTIFICATIONS can be set)

* If you create a callback with the type DEFERRED_CHANNEL_MESSAGE_WITH_SOURCE the only valid message flag you may use is EPHEMERAL.

The docs already state you may only set the ephemeral state of the message when using a deferred reply message on an interaction.

[TheKodeToad]

Indeed - I did notice this

The documentation does technically tell you this flag won't work here - but the alternative is not documented - and I am not sure whether this is a bug - but in any case the docs do need updating.

[PakjeBecel]

I already made a PR for it: #7507

[TheKodeToad]

Oh yeah. I was going to edit to link it lol. didn't make the connection that it was actually... you!