The issue is quite simple, running Message#delete passing a timeout as an option simply runs Message#delete on the said message timeout ms later, without checking if the message was already deleted or not. A check should be added to avoid API errors.
You could just handle the error in the catch block and see if the httpStatus returned is 404 or not.
client.on("message", (msg) => {
if (msg.content == "delete this") {
msg.delete({ timeout: 10000 }).catch((error) => {
console.log(error);
});
}
});
documentation - https://discord.js.org/#/docs/main/stable/class/Message?scrollTo=delete
Yeah but this is a monkey patching solution, we don't want to send useless requests to the API
The library should not be responsible for performing checks on the user's behalf.
If this is a concern for you, you can set your own timeout for deleting the message and perform checks/catch errors accordingly.
The solution for this issue is very simple to write, and there isn't any way to manually disable the timeout that Message#delete creates, so perhaps we should create this enhancement as a convenience. What are your thoughts?
My thoughts are written above
The library should not be responsible for performing checks on the user's behalf.
The way to "disable" the timeout is not to set one - it's effectively nothing but a glorified helper option for setting your own setTimeout anyway.
setTimeout(() => {
if(!message.deleted) message.delete()
}, 5000);
you could also extend the Message class using Structures.extend
to implement the desired behaviour if you wanted to, this would probably be the best soloution
I already did extend the structure but I believe most users would except such check. Beginners who set a timeout on a message in a channel that ends up being deleted will never understand where that error is from. But I'll close it if you believe it's not necessary. Basically agreed ElectrifyPro
In my personal opinion this points more towards removal of the option, leaving it entirely to the developer how to implement the timeout, with whatever checks and other functionalities in the callback as they deem necessary for their specific use case. We don't provide this on any other structures delete call, just on Message, where it was deemed useful before, due to the high volume of people asking for delays.
At the end of the day timers like this, which do not have a huge overhead in functionality (like for example collectors have as temporary event listeners, which are indeed useful to get additional user input - to name one example) are probably better left to set by the developer themselves.
https://discord.js.org/#/docs/main/stable/class/Client?scrollTo=setTimeout is available if the timeout should be cleaned up if the client is destroyed.
Most helpful comment
In my personal opinion this points more towards removal of the option, leaving it entirely to the developer how to implement the timeout, with whatever checks and other functionalities in the callback as they deem necessary for their specific use case. We don't provide this on any other structures delete call, just on Message, where it was deemed useful before, due to the high volume of people asking for delays.
At the end of the day timers like this, which do not have a huge overhead in functionality (like for example collectors have as temporary event listeners, which are indeed useful to get additional user input - to name one example) are probably better left to set by the developer themselves.
https://discord.js.org/#/docs/main/stable/class/Client?scrollTo=setTimeout is available if the timeout should be cleaned up if the client is destroyed.