Unknown Interaction

https://srcb.in/mgvjwip7A7 I am facing this issue when i am using /command

27 Replies

- 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!

d.js docs•5mo ago

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 responses

EASY TITLEOP•5mo ago

https://srcb.in/Aw1XOayGpD this is my first code https://srcb.in/Sy9E3plTXX this my second code Any suggestions

Unknown User•5mo ago

Message Not Public

He can walk•5mo ago

- Two processes handling the same command (the first consumes the interaction, so it won't be valid for the other instance)

Hello! Just asking: does it really throw a 10062? I thought it would throw a 40060 (Interaction already ACK) @KHUZUMI Do you still have the issue if you juste handle the interaction using await interaction.reply("test")? It sounds like you don't handle the interaction, so it expires after 3 secs (e.g. not-deferred interactions timeout). As suggested fellows just above, maybe you're also running two processes which can lead to unexpected behaviors. Maybe you should also try to reset your bot token to disconnect any other bot instance that could cause a conflict? Additionally, I suggest you to place some dumb console.log to see what happens in the execution flow of your code. I've just give a quick look to it and nothing seems to be really shocking. I would tend to say that using interaction.editReply in your final catch can be pointless, since you absolutely don't know in this part of the code if the interaction is still usable (you didn't check interaction.replied state, nor interaction.deferred). Finally, have you just a ping command which works and could you try to base your code on it to have some minimal force of debugging?

  if (
    !interaction.inCachedGuild() ||
    interaction.channel?.type !== ChannelType.GuildText
  ) {
    return;
  }

  const command = Object.values(commands).find(
    (command) => command.data.name === interaction.commandName
  );

  if (!command) {
    throw new Error(`Command \`${interaction.commandName}\` was not found.`);
  }

  if (
    !interaction.inCachedGuild() ||
    interaction.channel?.type !== ChannelType.GuildText
  ) {
    return;
  }

  const command = Object.values(commands).find(
    (command) => command.data.name === interaction.commandName
  );

  if (!command) {
    throw new Error(`Command \`${interaction.commandName}\` was not found.`);
  }

Doesn't seem relevant imo. Remove these excessive safety checks. You'll gain in maturity over time, and then know which safety checks are relevant or not, so that your app will also gains maturity in error-handling as well. Don't try to "Guess" errors scenarios, or you'll just handle errors that just doesn't exist. Also, ChannelType.GuildText DOES NOT mean you're covering all the text channels of a guild. For ref:

const __guildsChannelsWithTextChat = [
  ChannelType.GuildAnnouncement,
  ChannelType.GuildForum,
  ChannelType.GuildVoice,
  ChannelType.GuildStageVoice,
  ChannelType.GuildText
] as const;

const __guildsChannelsWithTextChat = [
  ChannelType.GuildAnnouncement,
  ChannelType.GuildForum,
  ChannelType.GuildVoice,
  ChannelType.GuildStageVoice,
  ChannelType.GuildText
] as const;

(However, I think it's too early in your project to manage those concerns...) Oof

      return interaction.followUp(`The ${title} title is currently locked.`);

      return interaction.followUp(`The ${title} title is currently locked.`);

? You should refactor the code so that you properly handle unhappy paths and early-terminations, and, imo... not like this. You call your command.execute as a void function, so keep it void. return interaction.followUp(_) is: 1. Pointless. You should just call the function, and just use return; after. 2. Super-dangerous: in Discord.js, almost EVERYTHING can throw. You should await it, or it will bubble and crash your whole program if it throws. Even in a try/catch, if you don't await it, it will just crash. I also don't understand why you use ADB? Delete everything that you don't actually need. (This point includes both stack inflation and excessive safety checks.) Also, the prisma client should be global, and NOT passed in arguments. This is also pointless, since the prisma client is INTENDED to be kinda global (just isolated in a TS file, as a module, and imported when you need to call it). And it is also intended to be spawned only one time, since it comes with a pool of connections. Just do this:

import { PrismaClient } from '@prisma/client';

export default new PrismaClient();

import { PrismaClient } from '@prisma/client';

export default new PrismaClient();

And import your prismaClient from this TS file whenever you need to use Prisma. Gotta go, GL

EASY TITLEOP•5mo ago

Actually i use adb to connect with a bluestack emulator because this bot handle a game I use this because if title is locked it show this massage to user

He can walk•5mo ago

Okay but it is not inteded to be used with return*, and this is expected to be prefixed with await, otherwise you risk to have very uncomfortable crashes * Except to manipulate an InteractionResponse object by yourself... I don't know anything about this usecase atm. Oh, okay. Makes a bit more sense to me.

EASY TITLEOP•5mo ago

https://srcb.in/zr89q03OLn showing this error This error comes sometimes https://srcb.in/GIOfgtWDQa here is my updated codes

He can walk•5mo ago

Considering the stacktrace, I bet the issue comes from setTimeout, line 228. I'm almost sure that you could implement this without using a weird setTimeout, using something from Discord.js which would be more predictible and easy to handle. Also, const hasProvidedCoordinates = x && y; is not a good approach imo. 0 is a falsy value in JS, so if your user put a Y Coordinate of 0, it will set hasProvidedCoordinates as false... I think you should do strict null checks. EDIT: checked and the pain point seems to be actually x, yes. Whatever. I just can't read code like this. Spoked a bit too fast: coerced it will result as false. So, in his use case, it will result as false.

He can walk•5mo ago

He can walk•5mo ago

https://discord.com/channels/222078108977594368/1255939279465615410/1256139211770429502

He can walk•5mo ago

¯\_(ツ)_/¯

He can walk•5mo ago

The coercion is implicitly made with the ! operator, so it will result as false in his if statement. The ! operator is basically a sugar syntax for !Boolean(x) Oh, wait, it will actually result as true for !0, yes. But then, what about null which is basically coerced the same? It will result as true too? So, what does mean hasProvidedCoordinates here?

He can walk•5mo ago

Well, okay You're too smart for me. This part of the code is purely incomprehensible for me and I bet it is glitched.

EASY TITLEOP•5mo ago

This issue come sometime and sometimes it run smooth without any error

He can walk•5mo ago

Then there's a bug

EASY TITLEOP•5mo ago

I can’t able to find a bug https://srcb.in/SPeiA1UKgA

He can walk•5mo ago

I think that more explicit and easier to reason code and some console.log to inspect values should clear up a large part of the problem, before considering a bug with Discord.js. Also, if the coordinates are intended to be both provided in your slash commands maybe just using .setRequired(true) in the builder should be fine? EDIT:

"You must provide both coordinaes if you provide one"

Well, no.

EASY TITLEOP•5mo ago

Can you read these codes please Please anyone help me i am much tired Anyone is here Can anyone available i can share screen of my pc When i run this bot a year ago then here was no such a problem But now this problem is coming. With this same code 1 year ago bot not show this problem https://github.com/daniellwdb/rok-title-keeper. Here copy of that bot src/commands/title.ts "discord.js": "^14.11.0" currently using this version

Yinoguns•5mo ago

@KHUZUMI Based on a scroll of the comments your issue stems from odd code approaches, which is not a DJS issue. I wouldn't hold your breath on assistance beyond what has already been said above.

EASY TITLEOP•5mo ago

So confused 🥺 Sometimes is run smooth and sometimes it give error Can someone modify my title.ts to fix this error please i am much tired @He can walk @Yinoguns

duck•5mo ago

this isn't really the kind of place where we write your code for you if you're having trouble understanding the info provided thus far, feel free to ask clarification questions though if you're just tired but could do it yourself, consider just getting some rest returning to this since I'm not sure if you were answered, but it does if both responses are sent at the same time (e.g. if two are sent asynchronously, even from the same process) you would get "Interaction already acknowledged" if they're sent one after another (e.g. awaiting one reply, then replying again)

He can walk•5mo ago

Oh, thank you! Makes sense to me now

Gaming

Programming

Unknown Interaction