Open Whuppee opened 1 year ago
no. this one happened on a fresh bot with no pre-existing embeds
~/discord-bot$ node ./server/build/index
[2023-02-10|21:39:31] - DATABASE - Main thread connected to db: test
[2023-02-10|21:39:31] - W - DEBUG - Acquire2 worker spawned.
[2023-02-10|21:39:31] - DATABASE - Acquire worker connected to database: test
[2023-02-10|21:39:32] - INFO - Commands appear up to date; hash is on1kLFBRJz/mwSN+Ua1Te4F8hGUg4WhgsBZcALMf244=
[2023-02-10|21:39:32] - M - DEBUG - DEBUG MODE ACTIVE
[2023-02-10|21:39:32] - INFO - Ready! Node version: v18.7.0
[2023-02-10|21:39:32] - M - DEBUG - Checking users for 888246961097048065
[2023-02-10|21:39:32] - DATABASE - We currently have 360 tracks in the test database, collection tracks.
[2023-02-10|21:39:32] - INFO - Web server active at http://localhost:2468
[2023-02-10|21:39:32] - DATABASE - WebServer worker connected to database: test
[2023-02-10|21:39:43] - COMMAND - Guild: Horse, User: Whuppee#6367, Command: play, Options: search - trainsong, what - playlist, shuffle - albums,
[2023-02-10|21:39:48] - M - ERROR - DiscordAPIError[10062]: Unknown interaction
at SequentialHandler.runRequest (/home/whup/discord-bot/server/node_modules/@discordjs/rest/dist/index.js:667:15)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async SequentialHandler.queueRequest (/home/whup/discord-bot/server/node_modules/@discordjs/rest/dist/index.js:464:14)
at async REST.request (/home/whup/discord-bot/server/node_modules/@discordjs/rest/dist/index.js:910:22)
at async ChatInputCommandInteraction.deferReply (/home/whup/discord-bot/server/node_modules/discord.js/src/structures/interfaces/InteractionResponses.js:69:5)
at async Module.execute (file:///home/whup/discord-bot/server/build/interactions/commands/play.js:32:9)
at async Client.<anonymous> (file:///home/whup/discord-bot/server/build/index.js:97:13)
node:events:491
throw er; // Unhandled 'error' event
^
Error [InteractionNotReplied]: The reply to this interaction has not been sent or deferred.
at ChatInputCommandInteraction.followUp (/home/whup/discord-bot/server/node_modules/discord.js/src/structures/interfaces/InteractionResponses.js:184:64)
at Client.<anonymous> (file:///home/whup/discord-bot/server/build/index.js:101:31)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
Emitted 'error' event on Client instance at:
at emitUnhandledRejectionOrErr (node:events:394:10)
at process.processTicksAndRejections (node:internal/process/task_queues:84:21) {
code: 'InteractionNotReplied'
}
This is truly a right and proper use of the existential horror tag.
In your first crash, pulling the relevant line out of the stacktrace:
at async Module.execute (file:///home/whup/discord-bot/server/build/interactions/buttons/queue.js:6:83)
This points to this line of code in the button file:
(which === 'showmedia') ? await interaction.deferReply({ ephemeral: true }) : await interaction.deferUpdate({ ephemeral: true } as InteractionDeferUpdateOptions);
which is further confirmed by the second crash on a fresh bot:
at async Module.execute (file:///home/whup/discord-bot/server/build/interactions/commands/play.js:32:9)
the indicated line of code being
await interaction.deferReply({ ephemeral: true });
All of that to say - at least to my eye, and I could be mistaken - these errors have nothing to do with embed tracking, player code, or websockets - somehow, we're losing the interaction before the initial deferral. The bot then properly crashes trying to edit a non-sent reply, which is expected(ish) behaviour. How we're managing to lose that interaction - especially in the play command code in the second crash - is an utter and complete mystery to me. There's basically nothing that happens in that code before the deferral, which makes me wonder if (and, to be honest, hope) this is a bug in discord.js or discord itself? I haven't dug too deep yet, but for code we've been using reliably for over a year it strikes me as odd we're only seeing these now.
another of these. local this time. confirms this wasn't to do with the deployed code being older
summarized sequence:
the 17:54:30 interval and web sync in the same second might be concerning, but my memory is ~3 seconds to reply/ defer; 20 seconds is unreasonably long. there's that 17:54:45 refresh and interval though, 5 seconds before the crash
also like last time, the time between pressing the button and the crash felt like less than several seconds, more responsive. I think the first refresh failed and—not confident this reconstruction—I think I noticed the failure and tried to refresh again, closer to the crash. probably just post-crash, else I can't explain it not being in the logs. when near simultaneously the audio cuts and discord reports the prior command having failed, nearer in time to my more recent refresh attempt