Rework Components deferring

[Luc1412]

Background Story

With the introduction of application commands (former: slash commands) interactions have been implemented. Those interactions need to be answered in 3 seconds which makes absolute sense because the user needs some sign of life from the bot. This deferring system has been copied to components that are also based on interactions.

The current problem

The major difference between deferring an application command or a component is, that deferring an application command states "Am alive. I need some more time to process the command. " and a component states "I finished the action" by ending the loading animation.

The main flaw: After deferring a component the user can provide his next input.
That means any action triggered by a component needs to be answered in 3 seconds.

How to solve it

There should be a way for a bot to acknowledge a component interaction. Afterward, the bot should be able to finish his action for 15min similar to slash commands. If the bot didn't answer after acknowledging, the interaction should throw an error.

[ghost]

as a hack, you can acknowledge component interactions by editing the message to the same thing it already is (or just provide an empty object, I think that works too)

[Luc1412]

That would be a similar result to defer. Unfortunately, there is no real option to display a loading state for more than 3 seconds.

[night]

The main flaw: After deferring a component the user can provide his next input.

Can you elaborate on this? We currently show a loading state when a deferred response is received until the message gets updated by the bot. You can then update the message according to further actions a user can take, if any.

[Luc1412]

After responding to an interaction in any way, the loading animation disappears and the components becomes clickable again. This allows the user to provide his next input.

Technically a bot is only able to process data that is required to respond to an interaction for 3 seconds.

[advaith1]

I think there is some misunderstanding here:

application command interactions can only be deferred one way: DEFERRED_CHANNEL_MESSAGE_WITH_SOURCE, which sends a "bot is thinking" response.

component interactions can be deferred in the above way, but you can also choose to use DEFERRED_UPDATE_MESSAGE, which acts as an "acknowledge" and allows you to use the interaction token later. it is intended to let you edit the message with the component later, but you aren't required to do that.

If you want to respond with a message, you should still use DEFERRED_CHANNEL_MESSAGE_WITH_SOURCE to get the "bot is thinking" message, even if it is a component interaction.

(also, slash commands are a type of application command, it's not a "former" name)

[applebee1558]

The issue here is if you do a DEFERRED_UPDATE_MESSAGE, it gets rid of the loading state, which lets the user click the button again. It's also excessive API calls to do one message edit that disables the button, and then edit to new content again. What we want here is a solution to defer the response keeping the loading state like slash cmds.

[advaith1]

responding with type 7 to edit the message and disable the button isn't any more calls than responding with a defer types

[applebee1558]

It’s an extra call when you want to do something that takes more than 3 seconds. You gotta use a type 7 or a type 6 if you ever want to edit the message later and not see an interaction failed. The issue is type 6 clears the loading state so people can click the button again. The current hacky solution would to do a type 7 disabling the button, and then another patch request to be what the final content is.

[ChrisTalman]

It's also worth noting that outright disabling the button on the message would impact all users, not just the one who pressed it. You might want to allow other users to press the button while other users are waiting for a response.

[ChrisTalman]

I agree, it'd be really nice to have a loading state for up to 15 minutes, just as with slash commands.

I'm curious as to why this is not already possible. It seems like an unusual inconsistency.

[Mehgugs]

This is possible with DEFERRED_CHANNEL_MESSAGE_WITH_SOURCE (this is how a slash command is defered). The issue is that there's no way to defer an edit and keep the loading state, not that there's no defer method at all.

[ChrisTalman]

Yes, I think that's what I and the original poster are highlighting.

We want the loading state.

It seems inconsistent that slash commands have a loading state but components don't.

[Mehgugs]

You can have a loading state but only if you want to send a new message, so it's not an inconsistency at all. It would be a welcome enhancement to components to be able to also have loading visible when you want to edit the message as well as just ackowledging the interaction, and I'm in favour of a new response type for components to do this.

[ChrisTalman]

Right, I just mean an inconsistency in the overall design.

If it's okay to display a loading state to the user for a new message for up to 15 minutes, including after they run a slash command, why not display a loading state on a component for up to 15 minutes?

From the user perspective, they're both things they have to wait for.

It's good to have DEFERRED_UPDATE_MESSAGE as an option, but it's really intriguing as to why Discord didn't just provide another response type alongside that which would display the loading state for up to 15 minutes.

Presumably it's either an accidental omission, or the designers didn't like the idea of components having a longer-lasting loading state.