Better user-facing errors for Interactions

[NovaFox161]

The Problem

With Discord pushing toward the use of interactions, I think a major pain-point for both developers and end users is the non-descriptive errors displayed in the client when the interaction fails.

End users often get frustrated when encountering an error, and that frustration is directed to the bot developer. However, many of these errors may not be the developer's fault, and it can be hard to diagnose when the only info provided to the user is "This interaction failed"

Listed below in no particular order are a few of the issues I have encountered myself, or seen the community encounter. This is not an exhaustive list.

Failing to ACK/reply within 3 seconds

There are a lot of different ways to reach this error point. For example, it is easy for developers first implementing interactions to get this as because they have not been made aware of the 3-second requirement. It may also happen if a bot is offline, which a user may not be aware of given the push to differentiate bots and users.

Proposed error message

"The application did not respond."

This message is clear and concise. It also informs both the developer and the user of the underlying issue.

Edit 01/11/22

This has now been implemented****(see below) and displays as "The application did not respond"
This is also shown on the 15-minute followup as well.

A number input is out of bounds of the min/max range #4040

As @caneleex brought up in their discussion, the current error of "Input a valid integer" is not a good error message. The user may have entered a valid number that is out of bounds or an invalid number. It is not clear.

Proposed error message

"Input a valid integer within (range)"

This message tells the user that their number is not in range, and informs them of the range. This would be far better than the current and vague message. An error message that includes the range would further improve UX by not relying on the developer to include the range in the option's description.

Edit 01/11/22

This has now been implemented**(see below) and displays "Input a valid integer from X to Y." (or "number" for a number option respectively)

When a global application command has been updated

The client appears to be aware that an application command has been updated, even when the cache has not been refreshed with the newest version. If this is the case, why not display that information to the user?

Proposed error message

"Command is outdated, please try again"

Ideally, this would not be needed if the 1 hour TTL can be reduced/removed. However, until then, a message is needed to inform the user that their command is outdated.

Edit 01/19/22

This has now been implemented****(see below) and displays "This command is outdated, please try again in a few minutes"

Summary

If interactions are going to be the main way bots interact with users, improved UI/UX needs to be a priority.

**Available on desktop clients, with iOS expected to support it in the coming weeks, and android lagging further behind.

[psibean]

Plus one for displaying min/max values in numerical option range errors - this was the very first thing I noticed as a user of my own bot and it felt like it would have been an obvious thing to include from the get-go. As it stands, us developers have to put the range information in our option descriptions, which isn't particularly great.

Ideally any numerical options with a min_value and/or max_value would show that on the option as it's in the menu / selected.

[Stalruth]

With respect to updated commands - no longer needlessly updating command versions on Bulk Update would help a lot.

[erkinalp]

The solution to that is:

• Allow applications to opt-in to precisely defined propagation delays #4025

[NovaFox161]

No. That's not a solution to it at all
A solution would be a server side diff check, not breaking the entire caching system.

[erkinalp]

@NovaFox161 That would make bulk application command updates atomic, without breaking the caching. The commands will propagate to nodes normally but remain disabled until exactly 3600 seconds after the bulk update request.

[NovaFox161]

What? Dude you are so off on what that means or the way the systems work. The current system isn't even exactly 3600 seconds. If you update a command 10 minutes before the cache flush. Then it's only a 10 minute wait. The commands do not have a global TTL.

Furthermore, that's not at all what atomic means and the open discussion you linked has no relevance to this discussion.

[advaith1]

responding to stalruth's original comment, the bug was fixed a bit ago

[NovaFox161]

Latest Q&A (summary here) the developers mentioned they will be doing a pass to make the errors received on interactions more user friendly. No word on when that will be but I'm glad to see that they are aware of it and intent to address it.

[NovaFox161]

Discord has implemented a better error message for inputting a number outside of the acceptable range. I'll keep this discussion as unanswered to help keep the community up to date on the gradual changes to error messages.

[yonilerner]

Failing to ACK/reply within 3 seconds

This has been done for Desktop/iOS and should be available on canary shortly

[typpo]

it's also been done for the 15 min followup timeout

[NovaFox161]

Thank you so much! Great to see these changes coming in

[imranbarbhuiya]

can we get this error message in message components also?

[typpo]

"Input a valid integer within (range)"

This is done on Desktop/iOS and is on stable

[yonilerner]

A new error message for outdated commands sent by clients will be released shortly

[NovaFox161]

Thank you!!

[NovaFox161]

As the errors mentioned in this discussion have all been improved, I'm going to be closing it. I want to say thank you to all the discord devs involved in improving the error messages, we all really appreciate it!

[yonilerner]

Just to clarify: "Across all clients" may be misleading as iOS support will probably not be rolled out for 1-2 weeks, and Android may lag behind for some of these by quite a while

[NovaFox161]

Ah, I'll fix the wording on that, thanks