Bug description
Java players connecting through the Connect Velocity plugin can briefly join and then be disconnected when nLogin/PacketEvents handles PostLoginEvent. The nLogin developer traced the failure to PacketEvents not creating/finding its expected decoder/player channel state for Connect's tunneled connection.
Original support thread: https://discord.com/channels/633708750032863232/1522200086648721498
Observed behavior
- Direct/non-Connect login works.
- Through Connect, the player briefly joins, then nLogin reports a severe internal error /
NullPointerException around VelocityPipelineInjector.setPlayer, followed by disconnects and downstream StacklessClosedChannelException writes.
login-reassert does not address the failure.
- The nLogin developer reports that PacketEvents does not create the expected channel because the tunneled path does not use the normal Velocity client-channel path.
Relevant Connect implementation
Connect wraps Velocity's serverChannelInitializer in VelocityInjector.VelocityChannelInitializer and feeds tunneled connections through a local Netty channel (LocalServerChannelWrapper). Velocity events fire, but PacketEvents expects the standard remote client channel/pipeline and cannot find the decoder/player handler when PostLoginEvent runs.
Source discussed in the support investigation:
https://github.com/minekube/connect-java/blob/main/velocity/src/main/java/com/minekube/connect/inject/velocity/VelocityInjector.java
Expected behavior
Tunneled Velocity connections should expose a pipeline/channel shape compatible with PacketEvents-based authentication plugins, or Connect should provide/document a supported integration hook so PacketEvents can bind the tunneled player safely.
Notes
- This report is only for the Java auth-plugin integration. The same Discord thread also contains separate historical Bedrock username-prefix discussion; that is intentionally excluded here.
- No existing issue matched
PacketEvents Velocity in this repository at filing time.
Bug description
Java players connecting through the Connect Velocity plugin can briefly join and then be disconnected when nLogin/PacketEvents handles
PostLoginEvent. The nLogin developer traced the failure to PacketEvents not creating/finding its expected decoder/player channel state for Connect's tunneled connection.Original support thread: https://discord.com/channels/633708750032863232/1522200086648721498
Observed behavior
NullPointerExceptionaroundVelocityPipelineInjector.setPlayer, followed by disconnects and downstreamStacklessClosedChannelExceptionwrites.login-reassertdoes not address the failure.Relevant Connect implementation
Connect wraps Velocity's
serverChannelInitializerinVelocityInjector.VelocityChannelInitializerand feeds tunneled connections through a local Netty channel (LocalServerChannelWrapper). Velocity events fire, but PacketEvents expects the standard remote client channel/pipeline and cannot find the decoder/player handler whenPostLoginEventruns.Source discussed in the support investigation:
https://github.com/minekube/connect-java/blob/main/velocity/src/main/java/com/minekube/connect/inject/velocity/VelocityInjector.java
Expected behavior
Tunneled Velocity connections should expose a pipeline/channel shape compatible with PacketEvents-based authentication plugins, or Connect should provide/document a supported integration hook so PacketEvents can bind the tunneled player safely.
Notes
PacketEvents Velocityin this repository at filing time.