#The user aborted a request. At Client.login.

77 messages · Page 1 of 1 (latest)

lusty girder
#

At some point after Dec 27, 1:30 PM (PST), my bot stopped running. I started it up manually (after making sure everything was up to date just in case it was an outdated node module issue), and this is the output:

[nodemon] 2.0.7
[nodemon] to restart at any time, enter `rs`
[nodemon] watching path(s): *.*
[nodemon] watching extensions: js,mjs,json
[nodemon] starting `node index.js`
Started notification cron job.
/usr/share/aocbot/node_modules/discord.js/src/rest/RequestHandler.js:201
        throw new HTTPError(error.message, error.constructor.name, error.status, request);
              ^

HTTPError [AbortError]: The user aborted a request.
    at RequestHandler.execute (/usr/share/aocbot/node_modules/discord.js/src/rest/RequestHandler.js:201:15)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async RequestHandler.push (/usr/share/aocbot/node_modules/discord.js/src/rest/RequestHandler.js:51:14)
    at async WebSocketManager.connect (/usr/share/aocbot/node_modules/discord.js/src/client/websocket/WebSocketManager.js:134:9)
    at async Client.login (/usr/share/aocbot/node_modules/discord.js/src/client/Client.js:254:7) {
  code: 500,
  method: 'get',
  path: '/gateway/bot',
  requestData: { json: undefined, files: [] }
}

Node.js v18.12.1

It appears to be having an issue logging in but I can't imagine why. Nothing's changed since then that I'm aware of, though I'm not sure how I'd check for shenanigans.

I appear to still only be using discord.js 13.3.1 even though I told it to update. Eventually I figured out how to update it to 13.12, but nothing has changed.

fickle shard
#

• 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.

lusty girder
#

already did all that mr bot

lean quailBOT
#

AbortError: The user aborted a request.
A request took longer than the specified restRequestTimeout (15 seconds default), and was aborted to not lock up the request handler.
• This can be caused by an internal server error on Discord's side, or just a slow connection.
• In case of a slow connection, the restRequestTimeout option in ClientOptions can be increased to prevent future AbortErrors.

lusty girder
#

I'll try it, give me a minute.

#

Gave it a 10 minute timeout, and it still didn't log in.

#

I don't think it's a connection speed issue.

#

I wouldn't rule out internal server error, but feels odd that there would be an API issue for this long instead of just... a me issue.

languid dust
#

where do you host your bot?

lusty girder
#

self hosted

#

same network I'm communicating from

languid dust
#

if your bot isnt logging in, that sounds like a connection issue of some sort

#

usually there would be an instant login request

lusty girder
#

What's the possibility of them revoking an authentication token? Or would there be a specific error message denoting that the authentication failed.

languid dust
#

you would get an auth failed or even an invalid token err if the token wasnt correct

lusty girder
#

If I can send a message to a webhook, would that help rule out anything?

#

That's something I can easily test with curl.

#

actually hang on

#

ah, damn

#

I had another bot running so I stopped it, and restarted it

#

now it gets the same error 😅

#

that's weird though cause I rebooted this machine today, meaning that connection was made today

languid dust
#

hm

#

sorry give me a minute to think

lusty girder
#

s'all good

languid dust
#

this only occurred today?

#

every other day the connection was fine?

lusty girder
#

no I believe this has been an issue for a couple days

#

I kept noticing in my web console that my systemd service for the bot had failed but I kinda just ignored it

languid dust
#

oh

lean quailBOT
#

Please add the following code to your code base outside of any other event listeners and provide the full log output relevant to your issue.

client
    .on("debug", console.log)
    .on("warn", console.log)

• Note: if you initialize your Client as bot or other identifiers you need to use these instead of client
• If the output is too long to post consider using a bin instead: gist | paste.gg | sourceb.in | hastebin

lusty girder
#

it wasn't a very important bot (the one that I stopped running kinda is though lol, so gg)

languid dust
#

might want to check the debug event

lusty girder
#

just copy/paste that line, don't add anything to it?

languid dust
#

mhm

lusty girder
#
Provided token: [redacted]
Preparing to connect to the gateway...
Started notification cron job.
[WS => Manager] Manager was destroyed. Called by:
Error [MANAGER_DESTROYED]: Manager was destroyed.
    at WebSocketManager.destroy (/usr/share/aocbot/node_modules/discord.js/src/client/websocket/WebSocketManager.js:317:54)
    at Client.destroy (/usr/share/aocbot/node_modules/discord.js/src/client/Client.js:284:13)
    at Client.login (/usr/share/aocbot/node_modules/discord.js/src/client/Client.js:257:12)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
/usr/share/aocbot/node_modules/discord.js/src/rest/RequestHandler.js:201
        throw new HTTPError(error.message, error.constructor.name, error.status, request);
              ^

HTTPError [AbortError]: The user aborted a request.
    at RequestHandler.execute (/usr/share/aocbot/node_modules/discord.js/src/rest/RequestHandler.js:201:15)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async RequestHandler.push (/usr/share/aocbot/node_modules/discord.js/src/rest/RequestHandler.js:51:14)
    at async WebSocketManager.connect (/usr/share/aocbot/node_modules/discord.js/src/client/websocket/WebSocketManager.js:134:9)
    at async Client.login (/usr/share/aocbot/node_modules/discord.js/src/client/Client.js:254:7) {
  code: 500,
  method: 'get',
  path: '/gateway/bot',
  requestData: { json: undefined, files: [] }
}
languid dust
#

i wonder if your bot is rate limited or blocked

#

or something

#

just a thought

lusty girder
#

rate limited would surprise me, these guys don't do much normally

#

blocked? well I can't say either way tbh, perhaps I'll try my dev-bot's auth token and see what happens

languid dust
#

anything in your code that would result in a rate limit?

lusty girder
#

I don't think so, not for this bot anyway

#

it only responds to user commands

#

it never does anything on its own

languid dust
#

seems like the debug log destroys the manager instantly for logging in

lusty girder
#

but that's it

languid dust
#

that shouldn't be an issue

lusty girder
#

especially weird that it allowed my other bot to log in today but doesn't seem to want me to now

#

offhand do you remember the url for the Discord dev portal

languid dust
#

yea for applications? or the docs

lusty girder
#

apps

languid dust
lusty girder
#

thanks 👌

languid dust
#

i'll be honest, this could be an ip block with that instant disconnect so this is a bit confusing to me

#

i could be wrong about that so forgive me

lusty girder
#

I hope that only affects bots if they did happen to do that 😳

#

otherwise I ain't coming back tomorrow aha

#

no idea why they would do that though

#

okay well I just logged in with another bot token

#

from a different machine to be fair, but it's on the same WAN address

#

let me try the real token on this machine too

languid dust
#

hm now im even more confused

lusty girder
#

yep still works

#

so it looks to be something with my server

#

unless they can IP block with NAT but I don't think that's a thing...

languid dust
#

nah

#

they would block the public IP so nothing would work, but thats not the case

#

there is a supposed connection since you get an HTTPError, but check your server's network stability

#

and network in general

lusty girder
#

pinged Google for 5 minutes straight, not a single lost packet. pretty good range of ping times too:

--- 8.8.8.8 ping statistics ---
306 packets transmitted, 306 received, 0% packet loss, time 305431ms
rtt min/avg/max/mdev = 9.379/16.901/25.684/2.327 ms
#

network seems fine

lusty girder
#

If anyone else has any ideas, @ me. And thanks for all your help Joe - I seem to have a very strange issue on my hands.

grand pendant
#

This may have cleared itself up.

lusty girder