fix(discord): make gateway close codes and resume outcomes unambiguous (#15) - #21
Conversation
…ecord the resume outcome
|
This pull request refactors the Discord gateway to make close codes and resume outcomes unambiguous in the logs, addressing the diagnostic challenges described in #15. It clarifies whether a close event originated from Discord or locally, and precisely reports the decision behind a socket opening (fresh identify or resume). This change is purely for instrumentation and does not alter admission or answering behavior.
Reviewers should begin by examining |
1 similar comment
|
This pull request refactors the Discord gateway to make close codes and resume outcomes unambiguous in the logs, addressing the diagnostic challenges described in #15. It clarifies whether a close event originated from Discord or locally, and precisely reports the decision behind a socket opening (fresh identify or resume). This change is purely for instrumentation and does not alter admission or answering behavior.
Reviewers should begin by examining |
Instruments the gateway so
wazootech/data#15can be diagnosed and its misleading log lines stop misdiagnosing it. No behavior change to admission or answering.The two defects in the log vocabulary
4002is Discord's decode error; the bridge also used4002for its own invalid-session close, soclose 4002in the log read as a Discord rejection while it was our own reaction to one. Local closes move to4900-4902(Discord's documented codes end at4014) and every close event is now rendered bydescribeClose(), which labels the side that raised it:local close 4902 (local: invalid session)vsDiscord close 4002 (decode error).gateway socket open (resume)was chosen by URL, not by decision. After the firstREADYthe resume URL stays in use, so a socket that was about to identify fresh still logged(resume). It now reports the decision:gateway socket open (fresh identify)orgateway socket open (resume from seq <n>).Evidence now recorded per cycle
resuming session <id> at seq <n>at the moment aRESUMEis sent.READYarrives while a resume is pending, the log says the resume was rejected and the session was dropped, rather than silently reporting a normalREADY.session invalidated by Discord (op 9, resumable=<bool>), annotated with, in reply to our resumewhen it answers one — this separates Discord invalidated the session from our resume payload was rejected, which is the open question in data-discord never completes a gateway resume, reconnecting every ~40 min #15.Verification
npm run typecheckis clean andnpm testis 30/30 (three new tests inlib/discord-gateway.test.tscover the close-code vocabulary, the local/Discord distinction for4002, and the transport cases).The underlying question in #15 — why the transport drops every ~40 min — is still open, and this change is what #15 asked for first ("log the raw close code and reason distinctly from our local close codes"). Once it deploys, one reconnect cycle is enough to tell a rejected resume from an invalidated session. #15's third recommendation (replace the hand-rolled gateway with a maintained client, as
FartLabs/goopdoes withdiscord.js) is a larger change and remains a decision, not something this PR assumes.