You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
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.
The text was updated successfully, but these errors were encountered:
Currently, when responding to a component interaction with
CreateInteractionResponse::UpdateMessage
, it is not possible to keep existing attachments on the message. This is because theMessage
andUpdateMessage
variants both useCreateInteractionResponseMessage
, which does not support specifying whether to keep attachments. It also seems like attachments are the only thing that is removed by default in anUpdateMessage
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:
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.UpdateMessage
to useEditInteractionResponse
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.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 itsexecute
function, it seems to be identical toCreateInteractionResponseMessage
. 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.The text was updated successfully, but these errors were encountered: