Player name lookups falling back to PlayerDB API instead of resolving locally

[derrickmehaffy]

Summary

Internal player name resolution in resolveUser() appears to be failing for both in-memory loaded users and storage lookups, causing all lookups to fall back to the external PlayerDB API (playerdb.co). This affects commands like /hp user <name> info, /hp user <name> setprimarygroup, etc.

Expected Behavior

Player lookups should resolve in order:

1. Loaded users (in-memory) — match against findUserByName() iterating getLoadedUsers()
2. Storage lookup — StorageProvider.lookupUuid(username) for previously connected players
3. PlayerDB API — only as a last resort for players never seen before

Steps 1 and 2 should handle the vast majority of lookups without any external API calls.

Actual Behavior

Debug logging from resolveUser() shows:

• findUserByName() reports "0 loaded users" even when players are connected
• Storage lookupUuid() returns empty (possibly due to cleared data, but needs verification on fresh data)
• Every lookup falls through to PlayerDB API

Impact

• Unnecessary external API calls on every player lookup
• Added latency for commands (HTTP round-trip to playerdb.co)
• Risk of rate limiting from PlayerDB API
• Username casing depends on PlayerDB response instead of local data

Investigation Needed

• Why does getLoadedUsers() not contain users for connected players?
• Is user data being loaded on PlayerConnectEvent correctly on prerelease?
• Does StorageProvider.lookupUuid() work after players have connected and data has been saved?
• Is there a timing issue where commands run before user data finishes loading?

Related

• HyperPermsCommand.resolveUser() handles the resolution chain
• PlayerDBService.java handles the external API fallback
• Debug logging was added to findUserByName() in a previous update

Labels

bug, priority:high