Unknown interaction
Hey! In 1 out of 20 cases, we encounter the issue that a response to an interaction returns an “Unknown interaction 10062” error, even though we respond within the specified time frame.
Is there a solution for this, or is this considered “normal”?
18 Replies
DiscordJS 14.21.0 and NodeJS 22
how do you know you reply within the time frame?
The error log arrives within less than 3 seconds after the interaction has been received
Common causes of
DiscordAPIError[10062]: Unknown interaction
:
- Initial response took more than 3 seconds ➞ defer the response *.
- Wrong interaction object inside a collector.
- Two processes handling the same command (the first consumes the interaction, so it won't be valid for the other instance)
* Note: you cannot defer modal or autocomplete value responsesthat suggests the 2nd or 3rd point then
What do you mean by "Wrong interaction object inside a collector."?
say you receive a slash command interaction, reply with a button, and create a collector to listen for its clicks
and then when receiving a button interaction, instead of replying to that, you reply to the slash command, which has already expired
something like that (pseudocode)
though that'd be kinda noticeable since that button wouldn't work at all
Okay, i understood
I will look into that, thank you :)
Is it wise to always defer all interactions directly? (where possible)
Is there a way to send a modal after the defer? Probably not?
no to both (you can't send modal)
only defer when you actually need it (or might need it), otherwise it's unnecessary
The problem is: (This has nothing to do with the problem from earlier)
The bot has grown very quickly, sometimes it doesn't take that long – sometimes it takes longer due to other jobs, because the load is high, etc.
Does that make sense then?
if all your commands need to do job logic or something else in order to work then yeah it might make sense to defer all of them
but say you have an /avatar command, that doesn't need any async or IO logic, it's a direct reply, so it's not needed
(just making an example, I don't know what you actually have)
It is not the logic itself that takes a long time, but rather the load throughout the entire process.
unless it's really overloaded (in which case you might want to shard) that probably shouldn't take much due to the event loop's workings
besides you said this
The error log arrives within less than 3 seconds after the interaction has been receivedso that suggests the time is not the issue
Yes, we have like 40 shards, with +/- 1600 guilds per shard, however, only 2 shards per bot process (cluster), so we also use the Presence_Update event, which (I think) causes the most load.
That's something else :D
it'd be better if you can describe the issue you want to solve with always deferring so we can have the full picture
You can ignore the 3 seconds from earlier – that's unrelated to the project.
It happens – the interaction (here too) becomes unknown – but probably because the load is too high and the code isn't completed within 3 seconds - even if it's not much.
The idea: We have now created an object for each type of interaction we have, e.g. TicketClaimButtonInteraction.
This tells us whether it can be deferred.
At first, the idea was to send a defer with a timeout of 2 seconds if the interaction had not been answered by then.
But that didn't work either, because unknown still came up from time to time.
The idea: a defer right at the beginning, before we do the rest.
Unknown User•2w ago
Message Not Public
Sign In & Join Server To View