Delete or hide messages

Hi.

In a conversation, we would like to delete all messages that are newer than some given timestamp.

If we want to remove everything since a given message, we can do something like this:

await bp
        .database('web_messages')
        .where({ conversationId: message.conversationId })
        .where('sent_on', '>=', message.sent_on)
        .orWhere({ id: message.id })
        .del()

Is it safe to perform such an operation? Is there a better way to get rid of messages?
Do we have to delete other data as a cleanup, like all the events that caused the deleted messages?

Alternatively…

I also tried hiding the messages in the chat instead of deleting them in the database.
I added a "deleted": true to the message payload, then used setMessageWrapper and hoped that I can just bail out, effectively hiding the “deleted” messages:

  if (props.wrapped.deleted) {
    return null;
  }

However, the message wrapper is only a child of the message group and can only hide the message itself, not the bubble.

Is it possible to replace the Message or MessageGroups components and return null there maybe?

Our current solution consists of a couple of steps, but effectively we don’t delete anything as that made things somehow unstable.

Instead, we go over the messages and update their payloads in the DB, adding an “obsolete: true” flag.
Then, we basically watch the store in the frontend and mutate it to remove the obsolete messages, basically with something along the lines of

store.updateMessages(store.currentMessages.filter(msg => !msg.payload.obsolete))

It’s okay as a workaround for now, however it does bring its own set of problems. For example, it seems there is a limit on how many messages are displayed in the chat, and if that is 100 and we have 100 messages marked as obsolete, we run into the problem of an empty chat…

Would be much better if we could omit those obsolete messages from queries - or actually really delete them from the database without causing problems elsewhere…

It seems that deleting the messages from the database is good enough after all. The perceived instabilities were side effects of a different issue.