Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CreateInteractionResponse::UpdateMessage should allow keeping existing attachments #3068

Open
DPlayer234 opened this issue Nov 27, 2024 · 0 comments

Comments

@DPlayer234
Copy link

DPlayer234 commented Nov 27, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant