Reconnect does not do its job
Closed this issue · 4 comments
The wiki says, when the proxy wants to reconnect, it exits happy.
The thing I get however is the following:
Current Queue Position: 88
ETA: 1h50m
Restart: Reconnecting now!
In Queue Server: TRUE
Mineflayer Running: TRUE
ELIFECYCLE Command failed with exit code 1.
From my understanding, 1 is sad, not happy. 0 is happy.
The output also gives no justification for why it has chosen this code. It even says it wants to reconnect.
Unless i'm horribly mistaken and 1 means success in javascript, in which case sorry for getting my small linux brain in your way (and i will never learn that language then).
NodeJS does actually follow the standard of exit code 0 meaning success and exit code 1 being an uncaught fatal exception (https://nodejs.org/api/process.html#process_process_exit_code).
You're right that the line from the wiki ("The proxy will only restart when the program exits with an exit code of "success", which it does when it wants to autoreconnect.") is actually wrong, it actually exits with code 1 (see: reconnect() function in proxy.js).
You may then be wondering why I chose to exit with this error code in the reconnect function; as am I, because I've forgotten.
Regardless, if pnpm run supervisor isn't working, then pnpm run supervisorAllGasNoBrakes should.
EDIT:
I remember why it exits with code 1 now, because of Supervisor being janky:
-n|--no-restart-on error|exit|success
Don't automatically restart the supervised program if it ends.
Supervisor will wait for a change in the source files.
If "error", an exit code of 0 will still restart.
If "exit", no restart regardless of exit code.
If "success", no restart only if exit code is 0
Why is it made like this? I don't know. >5-year-old issues about exit code jank, people making forks to fix single issues, et cetera. But at the time it Worked on My Machine so I just went with it ¯\(ツ)/¯
I.. didn't actually try with the supervisor, i just saw unexpected behavior and wrote an issue...
Regardless, either wiki or code should be fixed.
also, idk if this is related but sometimes the proxy doesn't even know it was disconnected. It restricts your movement or doesn't let you open storage but it doesn't close or etc., which is a bit not cool with the recent queue changes where you can apparently still skip the queue if you reconnect in a short period of time.
Without logs I can't be sure of the cause, but from experience I'm 99% certain that those cases of the "proxy not knowing it was disconnected" are actually cases the proxy has already disconnected and is waiting a bit before restarting, but the client or bridge is still sharing cached game state during this limbo state.
This can happen anytime the client is kicked uncleanly, and I noticed it the most when using hacks prone to getting the server's anticheat to kick you, which, unfortunately is difficult to debug and has only gotten worse over time.
The obvious solution is to just restart faster or send a custom kick packet to avoid confusion, but the default timers are very liberal to avoid getting stuck in a timeout loop of death from reconnecting too fast or erroneously thinking the client got disconnected during a lag spike and jumping the gun by initiating a restart. You can adjust these timers depending on your connection, but keep in mind that making the restart experience smoother won't solve the fundamental problem of getting kicked, which could be caused by a misconfigured hack client, the proxy, or a poor connection.
If you're using the proxy by yourself (i.e., not making an internet-facing ngrok tunnel), turning down the long default reconnect timer will allow you to skip queue. The default timers, as I referred to above, are geared for high-uptime servers meant to be deployed once and never get stalled at the expense of some slowness; you'll want to tweak them, esp. if you're only proxying a small amount of accounts.
So probably just change the wiki to say it returns 1 instead of 0, and problem solved. The supervisor works btw.