When an interaction event is received from the gateway, the library is able to acknowledge them automatically. This allows to simplify your code a lot, as you can directly use
editReply() without worrying about choosing between
deferEdit() first. If you have a specific use case that requires you to take full control over the acknowledgment process, the library gets you covered by offering a way to disable automatic acknowledgment on a per-command basis.
This was partially covered in the Configuration page, the default behavior can be set via the
default_ack_mode field of
config.json if you are using the Botrino framework, or via
InteractionConfig.Builder#defaultACKMode(String) when building the configuration manually. Here's a table describing the possible values and their behavior:
deferReply() (for commands) or
deferEdit() (for components).
deferReply().withEphemeral(true) (for commands) or
deferEdit().withEphemeral(true) (for components).
|Does not call any acknowledgment method.
Let's say you have
defer as default behavior in your config, and you want to make a command that replies exclusively with ephemeral messages. There would be no way to achieve this without overriding the acknowledgment behavior for this specific command so that it can be ephemeral. This is as simple as adding an
@Acknowledge annotation with the desired mode as value:
Since this is a very simple command, you could even completely disable automatic acknowledgment and use
reply() instead of
If your command is made of subcommands or subcommand groups, the
@Acknowledge annotation must be used on the listener implementation class of individual subcommands; putting it on the parent class alongside
@ChatInputCommand will have no effect.