DiscordAPIError[10062] With no consistent reproducibility

Good evening! Thank you for taking the time to read my post, I am very much a beginner learning/teaching myself JS using discord.js and my discord bot is my project to do so! I appreciate any patience offered and will do my best to research any answers provided - Really I am looking for any direction to resolve my issue. This has become more prevalent over the course of a few weeks. Issue: Encountering a DiscordAPIError[10062] in bot’s logs, leading to a “The application did not respond” error for users.
Observations:
The error is random in users affected, time, and commands. Commands usually work after retrying. Even simple commands (like a send message command) experience this issue. I can’t replicate the problem.
Environment:
My bot is hosted locally on my PC using pm2. I have a stable gigabit internet connection.
Troubleshooting Steps Taken:
Attempted to replicate the issue without success. Added timestamps to catch response delays(waiting for results). - Commands never fail response delay otherwise, deferred or not deferred. No collectors or duplicate processes for commands. reverted changes that may have caused the issue. Any guidance is very much appreciated! Happy to provide any further information. Not 100% sure of the best applicable code - just in case my interactionCreate and InteractionErrorHandling as it is listed in the error (boiled down):
if (interaction.isChatInputCommand()) {

// Mod, defer, cooldown logic

if (!cooldown) {
try {
if (interaction.isCommand()) {
await interactionErrorHandling(command.execute, interaction);
}
if (interaction.isChatInputCommand()) {

// Mod, defer, cooldown logic

if (!cooldown) {
try {
if (interaction.isCommand()) {
await interactionErrorHandling(command.execute, interaction);
}
InteractionErrorHandling:
async function interactionErrorHandling(interactionFunction, interaction) {
try {
await interactionFunction(interaction);
}
catch (error) {

const event = 'interaction';

// Pass to local define and logging
localErrorLogging(error, interaction, event);

// Send a message to the user
async function interactionErrorHandling(interactionFunction, interaction) {
try {
await interactionFunction(interaction);
}
catch (error) {

const event = 'interaction';

// Pass to local define and logging
localErrorLogging(error, interaction, event);

// Send a message to the user
disc 14.14.1 node v21.6.0
No description
3 Replies
d.js toolkit
d.js toolkit3mo ago
- What's your exact discord.js npm list discord.js and node node -v version? - Not a discord.js issue? Check out #other-js-ts. - Consider reading #how-to-get-help to improve your question! - Explain what exactly your issue is. - Post the full error stack trace, not just the top part! - Show your code! - Issue solved? Press the button!
Sun
Sun3mo ago
Thank you for your thoughtful and in-depth response Qjuh! In a somewhat interesting turn of events - The error happened live while I was responding to you and you are absolutely correct it comes down to the interaction.reply in the live example, line 96 in my pull command:
await interaction.reply({ content: `<@${interaction.user.id}> pulled ${count} ${identifierEmojis[shard]}`, fetchReply: true });
await interaction.reply({ content: `<@${interaction.user.id}> pulled ${count} ${identifierEmojis[shard]}`, fetchReply: true });
What leaves me a bit in the dark is the commands were being actively used not long before that without issue, in a similar time frame, without triggering the error, likewise it has triggered after no other interaction for several hours. To follow your insights: - It may simply be a connectivity issue on my end, I've had no way to connect the two unfortunately. I am the only active user and there was no strain on the network that was present with the live error. - This is something I will dig much deeper into today as I did not yet fully go down that path. - As a beginner I believed (naively I imagine) that this was not likely as the commands functioned, without issue, rapid fire including when switching between any and all of them. - Some functions do have I/O tasks, it seems to indiscriminately error whether it does or not. I will follow up with this as well as part of suggestion two! Unfortunately my localErrorLogging is in current form a bit misleading in title, it simply logs the errors to my db. I did receive interaction args with this live error I can provide, perhaps this does offer a bit more insight as it is more extensive than before. (color coded same users)
No description
Sun
Sun3mo ago
Absolutely! I appreciate you taking the time. Feel like a bit of a fool could have posted the git anytime: https://github.com/sun-cv/Bot_Geo The Pull command specifically: https://github.com/sun-cv/Bot_Geo/blob/master/commands/mercy/pull/pull.js I see! Perhaps this was a wrong impression I caught early on, what I believed to more or less mean: "never defer unless absolutely needed" - and as such have followed that practice Could this just have been bad advice and is there no harm in doing so? Especially when I am awaiting multiple functions inside of the commands? I need a Piccard level face palm for that one haha Just to ask as a follow up - my understanding of asynchronous tasks was that they can continue to process all at once - unless we are resolving a specific promise in which case we have to await that resolve/reject. When you say to defer before async tasks you mean when we are required to wait/resolve those functions inside a command? Awesome thank you! That is definitely awesome information to have corrected - and gives me a bit of work because that is practically how every command I've made so far is built haha. If you have a spare moment sometime (of course feel no obligation I appreciate all of your help so far!) would you mind looking at the ping command with me? https://github.com/sun-cv/Bot_Geo/blob/master/commands/utility/ping.js I have seen the exact error on this command as well and it is I believe a full async task (minus the interaction.reply) - there is no resolving required just simple if true checks and it has still triggered that error before. Unless I am missing something entirely it seems like we may still not be at the root cause? I did not consider that! Yes the await activateUpdateUser(interaction); is an async call and this does check the db. I previously had this as a header more or less on each individual command, thought it would be simplified here as this will be called on every interaction the same way. It seems like this is not the wisest decision in hindsight. I imagine my belief "it never takes more than ms to run x so it shouldn't cause a problem" - is absolutely faulty logic. So I need to fully rethink how I handle these interactions and commands, and rework a large portion - I am thankful just to have a direction to move in. I believe I may have saved myself a bit of work in how I implemented a potential defer mechanic (which I haven't used or tested yet but will get plenty of practice with) where I intended to "import" the defer in the command call in the interaction handler:
const {
data = null,
moderator = false,
maintenance = false,
deferReply = false,
cooldownCount = null,
subCommand = null,
subCooldownCount = null,
} = command;

if (deferReply) {
console.error('defer command');
console.error(interaction.member.user.username, interaction.member.id);
interaction.deferReply();
console.error('exit', interaction.member.user.username, interaction.member.id);
}
const {
data = null,
moderator = false,
maintenance = false,
deferReply = false,
cooldownCount = null,
subCommand = null,
subCooldownCount = null,
} = command;

if (deferReply) {
console.error('defer command');
console.error(interaction.member.user.username, interaction.member.id);
interaction.deferReply();
console.error('exit', interaction.member.user.username, interaction.member.id);
}
I genuinely appreciate all of your insights so far Qjuh, hopefully it comes across that this has been an awesome learning experience for me! I'd been flying completely solo so far lol. If there were any other take-aways or suggestions you feel might be relevant or something you feel I should implement (or most likely misunderstood!), I would be all ears and most appreciative!