Previous grace-window fix only kicked in when self.hasItem was already
set, so first-render-under-lag (login/reloadui while bag data is in
flight) still drew empty. Arm a single re-verify on any nil read so a
late-arriving item gets redrawn; the verifyArmed flag prevents
re-scheduling on genuinely empty slots — it only clears when we see a
valid link.
GetContainerItemInfo returns nil for some occupied slots during server
lag, causing Bagnon to draw the slot empty. Earlier retry-polling
approach caused massive lag because every legitimately emptied slot
also matched the "previously had item, now nil" condition and ran ~30
live reads over 3s per move.
New approach: on a nil-after-occupied read, if we're within
GRACE_WINDOW (0.5s) of the last good draw, keep the prior draw and
queue ONE re-check at the deadline — no polling. A genuinely emptied
slot resolves at the deadline; a recovered slot redraws with correct
data. lastGoodTime is set only on non-nil reads, so persistent lag
eventually accepts the empty.
The event-level retry only protected the ITEM_SLOT_UPDATE broadcast, but
ItemSlot:Update() reads GetContainerItemInfo live on every call and is
invoked from many paths (OnShow → ReloadAllItemSlots, AddItemSlot,
BAG_UPDATE_TYPE, search updates). On a laggy server those live reads
flash slots empty. Add a shared retry queue at the slot-render level so
a slot with self.hasItem set will defer rather than draw nil; cap at
RENDER_RETRY_MAX so a genuinely emptied slot still resolves within ~3s.
florian.berthold
andrew6180
Matthew Rodrigues