Message with `SUPPRESS_EMBEDS` can still have embeds.

[wtgtybhertgeghgtwtg]

Description

I have been working on a bot that can suppress embeds for messages with specific URL's. An intermittent issue that I have been running into has been a message with a suppressed embed showing that embed anyway. This seems to be happening when the call to suppress embeds resolves before the server can discover what it would embed.

Steps to Reproduce

Create a bot that will immediately suppress the embeds of a message. With discord.js, it'd be something like

import {Client, Intents, Message} from 'discord.js';

const client = new Client({
  intents: [Intents.FLAGS.GUILDS, Intents.FLAGS.GUILD_MESSAGES],
});

client
  .on('messageCreate', (message) => {
    console.log({messageId: message.id});
    message.suppressEmbeds().catch(() => {});
  })
  .on('messageUpdate', (oldMessage, newMessage) => {
    console.log(
      {
        messageId: oldMessage.id,
        newEmbedsCount: newMessage.embeds.length,
        newFlags: newMessage.flags,
        oldEmbedsCount: oldMessage.embeds.length,
        oldFlags: oldMessage.flags,
      });
  })
  .once('ready', () => {
    console.log('The client is ready.');
  });

client.login(YOUR_TOKEN_HERE).catch(error => {
  console.log('The client failed to log in.');
});

In a channel the bot is active, enter some URL (ideally a page from a site that has a degree of latency, or using a URL shortener). Several URL's may have to be used, since Discord seems to have a cache mechanism for embeds.

Expected Behavior

The message should not have any embeds at any point after the call to suppress embeds resolves.

Current Behavior

The message may have an embed, even with the SUPPRESS_EMBEDS flag.

Screenshots/Videos

No response

Client and System Information

Chrome 98, discord.js 13.6.0, Linux Mint 20.3.

[gamer0mega]

The embed loads after some time, not immediately, try suppressing in the message update event

[wtgtybhertgeghgtwtg]

While that does work (and is the current work-around)

client
  .on('messageUpdate', (oldMessage, newMessage) => {
    if (
      newMessage.embeds.length > 0 &&
      newMessage.flags.has(MessageFlags.FLAGS.SUPPRESS_EMBEDS)
    ) {
      newMessage.suppressEmbeds().catch(() => {});
    }
  })

it is not behavior I believe I should depend upon. Suppose, for example, there's a server update with a performance optimization that adds a short-circuit on calls to suppress embeds for a message with the SUPPRESS_EMBEDS flag. For the code above, that could mean that it would not remove the embeds, but still trigger the 'messageUpdate' event. Since the if condition would still be true, it would send another call to suppress embeds, which does not remove the embeds, but triggers the 'messageUpdate' event again, in a loop. So now my code, which was benign, is now spamming the server with calls, with whatever repercussions that may have.

[night]

It looks like we are already checking for the suppress embeds flag when resolving embeds. If you are still seeing this behavior, it is most likely a race condition and your change to wait for us to finishing resolving embeds is likely the best fix. As we intentionally do not lock around message mutations and last writes win, this is unfortunately not easily fixable in our infrastructure.