PlayerDataSync

[26.9-Release] - 2026-09-10

Fixed

• Old armor / inventory coming back after a server switch: Three ordering races in SyncManager could apply a stale record over the player's real state. (1) The join event, the Velocity load: message and the Redis notify each started their own DB load; two loads ran concurrently and whichever finished last won, even if it had read the record from before the previous server's save landed. Loads are now serialized per player: a load requested while one is in flight is queued and runs afterwards, so the newest record is always the one applied last. (2) Autosave, the proxy save: message and quit could all save while the join load was still pending, writing the server's local playerdata (the player's state from their last visit) over the record the previous server had just written. Saves are now refused until the stored record has been applied. (3) A late Redis reload re-applied a record the player already had, rolling back anything done since (e.g. newly equipped boots). Records now carry savedAt; re-applying the same record within a session is skipped unless forced via /pds load or PlayerDataSyncAPI#forceReload.
• Failed SQL saves were reported as successful: SqlStorage#save swallowed SQLException, so SyncManager cached the inventory hash (skipping the next save as "unchanged") and told other servers to reload. The future now fails, the error is counted, and the next save retries.

Added

• Unit tests for the SyncManager join/quit ordering (common/src/test), run via gradlew :common:test.