Error Message as Interaction Response

[kingmigdor]

I got the idea today to make an interaction response for the error message. Since modals popup and user may submit wrong information, people may want to know, what the error actually is, but don't want to close the modal and open it again. So I thought about making a response for that.

This can also be useful in other interactions, because bots can give more accurate information about the error. Yes, it is possible to do this with a message, but ephemeral messages need to get dismissed or there will be a public message which is not that useful. So why not adding the error response to ALL interactions?

This is an example for a button that only one user should be allowed to use. The bot responded to that button with "You are not allowed to use this button."
It can also be useful for buttons with a timeout or something.

In modals we have an error message inside of the modal, which means, bots can have their error there (ignore german language):

Interactions are always designed to have an "This interaction has failed" error message. This will always be the message where the error will be shown, that the bot has responded to.

In autocomplete interactions, it would simply be under clyde, but I was not able to edit that xD

Fields in the interaction data:

content - The content of the error message
Since there's no other useful information an error message could have, we only need content.

Hope this feature will get added. Feel free to ask me, if you have questions about this idea.
Cheers!

[Tais993]

It'd be nice if a Discord error could be differentiated with a bot error, but besides that this would be lovely

[kingmigdor]

Hmm yeah. Maybe just show a little bot icon next to the error message and when you hover on it it says smth like "Beep Boop, something happened wrong with the bot" or some funny text.

[Mehgugs]

I think this is necessary for slash commands and it worries me that something like this does not already exist today.

This would work better as a separate endpoint, so that defered interactions could also have an error response. I think
something along the lines of POST /interactions/{interaction.id}/{interaction.token}/error .

In general, I don't think ephemeral messages solve this problem because their formatting is chosen by the individual developer, and errors should all look the same so users recognize them as errors.

[rouven0]

This would also be a great idea for bots that receive their interactions via webhook. There the app could use http status codes to indicate validation errors (code 400 for example) or Cooldowns(429). Additionally the response can contain errors message similar to the ones discord provides in API v9 and above.

[Mehgugs]

How would this work if you defer then wish to respond with an error? Using http semantically is quite cute, but in this case rather brittle because of deferral and does not have a clear gateway analogue.

[kingmigdor]

You'd be still able to respond with an error. That would behave the same as followup messages after the defer, like if you defer non-ephemeral and the interaction times out, the error would also be non-ephemeral.
Same thing would go with "respond with a message to error", there's nothing that would be changed. If you defer non-ephemeral and wish to answer with an error message, there's no way to make this ephemeral.

[Mehgugs]

You didn't read what this was in response to:

There the app could use http status codes to indicate validation errors

That is what I'm suggesting has an issue with defering, I've already made the case for what you've described in this same thread.

[shaydewael]

For now, ephemeral messages could be used to reply to interactions to display errors to a specific user.

That said, I understand that they don't have the same error styling, and I could definitely see how it would make a good addition and make app errors feel a bit more native.

[Mehgugs]

ephemeral messages could be used to reply to interactions to display errors to a specific user.

I don't think ephemeral messages are a suitable stand in for errors, not only because of the experience in app but because to do this generally you need to be able to send an ephemeral message at any point in the interaction flow that you might have an error crop up.

Imagine you're writing a library, and wish to have an error method/function. Maybe it might look something like this:

function myInteractionCallback(ctx) {
   ctx.defer(); // not ephemeral because we want to reply publicly 
   let somethingCool = someExpensiveAsyncOperation(ctx.args[0], SIXTY_SECONDS);
   if (!somethingCool) return ctx.error("What should this do?"); // ctx will need track all the possible states internally
   //....
} 

So you've got to get the UX right by yourself, discord can't help you there, and you've got to write library code that is able to respond with an ephemeral message from any given interaction state. There are some arbitrary choices here too, for example how should you report errors in/from modals? Every library is going to do this differently.

Now imagine you've figured out all the distinct routes you'll need to take to get an ephemeral message out to the user. Discord now announces that they've added a new interaction response type, you've now got to figure out a new bespoke path for errors.

To put this into a hyperbole analogy: it'd be like only being able to use a try/catch statement if you knew the context of the call stack.

If this isn't implemented before release, every library and bot will do it differently. Then when better error support is finally added adoption will be slow because people already had to solve the problem themselves. Looking at the past year of development I would have thought discord would be aware of this fact.

[kingmigdor]

Somehow, an user needs to close the modal to read the error and then re-open the modal. If that case is unhandled, all fields are cleared.
That would be the worst behaviour users can expect. So unlikely, if something is wrong in the modal, bots don't have a great option to tell the user actually what's wrong with that.
Also when pressing a button, most people are saying that the fact of scrolling is really bad. Imagine needing to scroll down to read the error message and then scroll back up to retry.

[quirky-bluejay]

In addition, when using selects, using an ephemeral response as an error message means that what is selected in the select changes. (When an interaction fails, for example, what is selected is reset).
An error response type could help with this

[showengineer]

For HTTP-only bots, I can see them simply returning a 4xx or 5xx with a simple message in their body. All Discord has to do is set that message for the error message.

[Zuzuesque]

My issue with the ephmeral response suggestion is that users have to re-enter potentially long responses upon failure.

Example: I got a modal with two textfields and two text areas. One textfield needs an official timezone name to work and my bot validates it upon submission. If the user enters erroneous data (because he isn't familiar with timezone names), he has to enter the whole info again--including the two text areas. Can I dump all his inputs into a reply and try to parse it back into a new modal using a retry-button? I guess. But it would be more user-friendly if the modal stayed open so a user only has to edit the fields failing validation.