minecraft/conn.go: Re-check deferred packets on expect() to prevent handshake deadlock

[iteplenky]

When a server sends ResourcePacksInfo before PlayStatus(LoginSuccess),
the packet gets deferred because its ID isn't in expectedIDs yet. When
PlayStatus later arrives and expect(IDResourcePacksInfo) is called,
the already-deferred packet is never re-checked — causing Dial() to
deadlock waiting for a packet that's already been received and discarded.

This adds handleDeferredPackets() which is called from expect() to
re-process deferred packets against the updated expected set. Packets
that still don't match are re-deferred by handle() automatically.

Observed on: Hive, Lifeboat, Galaxite (intermittent, depends on packet
arrival order which varies per connection).

[TwistedAsylumMC]

I would change this to be conn.deferredPackets = conn.deferredPackets[len(deferred):] just to keep the pre-allocated size

[HashimTheArab]

you can just add resourcepacks info to this list

gophertunnel/minecraft/dial.go

Line 298 in 9c440d5

conn.expect(packet.IDServerToClientHandshake, packet.IDPlayStatus)

[TwistedAsylumMC]

you can just add resourcepacks info to this list

gophertunnel/minecraft/dial.go

Line 298 in 9c440d5

conn.expect(packet.IDServerToClientHandshake, packet.IDPlayStatus)

I guess it depends how far the client lets you go with the ordering of these packets. The PR's implementation is the most future-proof way, but if the fix you've provided is solid enough then maybe it's better to merge that over this

[HashimTheArab]

been using it for over a year

[TwistedAsylumMC]

My point isn't for what works currently, it's what is best going forward so we don't need to make yet another change when a server sends a packet in a slightly different order that isn't caught by the current code

[HashimTheArab]

ik i agree

[iteplenky]

@HashimTheArab Re: adding IDResourcePacksInfo to the initial expect() at dial.go:298 - that works for this specific case, but the root cause is that expect() never re-checks already-deferred packets. If any other packet arrives out of order in the future (e.g. ResourcePackStack before ResourcePackDataInfo completes), it would deadlock again and need another hardcoded addition.

The handleDeferredPackets() approach fixes it generically: whenever expect() updates the expected set, all deferred packets are re-evaluated. No future changes needed regardless of server packet ordering quirks.