Repository navigation
fix(Teleport): discard delayed requests on disconnect - #9366
Conversation
|
Thanks for this — the state carry-over between connections is a real gap, and opting into the existing One review point: the diff itself only flips the flag, so it relies on Docs impact looks nil: the Teleport page still describes the module as command-driven and its settings are unchanged, though you may want a sentence there about the queued request not surviving a disconnect. A maintainer will take it from here. 🤖 Automated support reply — a human maintainer will review if this doesn't help. |
onDisabled() is now also reached by quitting, so the disabler armed by WithDisablerOnWait needs the same release the position packet handler does. The useCommand path queues its auto disable instead: mc.execute runs inline on the game thread and is defeated by the enabled value not being committed yet.
2 participants
Disconnecting while a delayed teleport is armed leaves the module enabled with the previous connection's destination and correction counter. Position corrections after joining another world can execute that old request.
Opt into the existing
disableOnQuitlifecycle soonDisabled()clears the pending request before leaving the world. Adds a client regression for disconnect/rejoin, subsequent position corrections and a fresh delayed request in the new connection.Related to #9327, finding E.
Validation: build and client game tests passed. The added regression also fails for its intended reason on unmodified sources.