Skip to content

CreateInteractionResponse::UpdateMessage should allow keeping existing attachments #3068

@DPlayer234

Description

@DPlayer234

Currently, when responding to a component interaction with CreateInteractionResponse::UpdateMessage, it is not possible to keep existing attachments on the message. This is because the Message and UpdateMessage variants both use CreateInteractionResponseMessage, which does not support specifying whether to keep attachments. It also seems like attachments are the only thing that is removed by default in an UpdateMessage response.

Discord already allows keeping attachments in this case, and the underlying logic in serenity seemingly does too, it just isn't exposed. You can also keep attachments by first using Acknowledge and then editing.

I can handle the implementation, but I'll need some guidance on the preferred way to fix this. The following options come to mind:

  1. Add new methods to CreateInteractionResponseMessage to allow keeping attachments. In this case, the current default of "remove all attachments" should still be respected, and potentially have a way to be overridden.
  2. Change UpdateMessage to use EditInteractionResponse instead. This may more closely match expectations also. Most of the fields missing here don't seem to be supported on edits anyway, but the flags might be needed. May have to look into which of the documented allowed flags are respected.
  3. Provide an entirely new builder type. This seems like overkill to me.

Option 1 would keep backwards compatibility, but usage and behavior would differ from other edits. Options 2 and 3 would be breaking changes, but it would be consistent with other message editing builders.

This seems to also affect editing interaction follow-ups in general, since both creating and editing them uses CreateInteractionResponseFollowup. Besides its execute function, it seems to be identical to CreateInteractionResponseMessage. It might be worth unifying these two types into one if a breaking change is taken already. Whatever approach to allow keeping existing attachments is chosen however, we should apply the same one to follow-ups.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions