Fetching webhook breaks inconsistently
I have a command that takes a webhook URL and should do something (haven't gotten there yet) with it. It works fine if I start up the bot and call it on a valid URL.
However, if I call this command on a webhook URL with an invalid token, then when I call the command again with a valid URL, it does not work until I restart the bot.
This is the core of the code:
The error I get when I use it on an invalid URL is this:
Then, when I use it on the correct URL with the correct token, I get the following:
Except, the
console.log(match[1], match[2])
indicates that I am providing the token in the Client#fetchWebhook
call.2 Replies
• What's your exact discord.js
npm list discord.js
and node node -v
version?
• Post the full error stack trace, not just the top part!
• Show your code!
• Explain what exactly your issue is.
• Not a discord.js issue? Check out #useful-servers.hm, it looks similar, but i'm not using djs/rest so i am not sure if it is caused by the exact same thing - (also yeah unless i missed it i don't see a fix there? looks like a similar issue though)
ah oops
alright lemme try to test that
hey sorry how do I test that?
i've never used djs/rest before; currently just trying the following
(just inserted this right before my login line)
but i am not getting any output
oh thanks lol
the issue happens only after i fetch an invalid URL; i've been doing this previously as well and never had issues since i never tried entering an invalid URL
oh like through
client.on
? not sure how to do that either sorry
wait, like it unsets the client's token or something?
since I do provide the webhook's token again in the next call
anyway yes, I do get a 401 from the invalid webhook fetch which then causes the subsequent GET to not even be called
oh interesting
i suppose i could just fetch it without the webhook token then, since the bot does request Manage Webhooks...
lmao rip
oh weird ok
so would a workaround be to just set the client's token again if this GET fails?
hm, yep adding a cmd.client.rest.setToken(...)
in the catch block does fix this
alright thanks ❤️ that's pretty scuffed though but it works so oh well
can't wait to run into some weird race condition 3 months later when someone else's command invocation fails between when the REST client discards its token and when i can set it back