Can't pay employees .Savannah212467 and .Dps1234_2541 from a government account. The leading dots mark these as Floodgate/Bedrock usernames.
The gov-pay recipient is resolved by the same cache-only Bukkit.getOfflinePlayerIfCached path as PAR-150 (GovCommand / Hibernia OfflinePlayerResolver.java:30). That resolver is intentionally Bedrock-safe (it avoids the Mojang lookup), but it still returns null for any name not in the usercache — so this is most likely the same uncached-name failure as PAR-150, surfacing on Bedrock employees who aren't currently cached. Secondary possibility: the leading . is stripped or rejected somewhere in arg parsing / a VALID_PLAYERNAME-style regex (cf. the Bedrock-hostile defaults flagged in PAR-109).
.Savannah212467 is in the usercache when the command fails; log the exact arg string reaching getOfflinePlayerIfCached.firm_players / the PAR-35 economy_players table, which already stores Bedrock names including the dot).. (cf. PAR-109).Related: PAR-150 (umbrella cache-resolution bug), PAR-109 (Bedrock name handling), PAR-35.
Resolved by PAR-150 (commit
d37ab36)."Pay employees from a gov account" is
/gov payout <govAccount> <employee> <amount>(GovCommand.doExternalPayout). That path now falls back to the PAR-35economy_playersdirectory (PlayerDirectoryService.resolveUuidByName) on a usercache miss, and the directory resolves Bedrock/Floodgate names verbatim — the leading.is preserved (covered byPlayerDirectoryServiceIT.resolveByName_resolvesBedrockNameVerbatim). So.Savannah212467/.Dps1234_2541resolve whether or not they're currently cached.Secondary hypothesis from the report (a
VALID_PLAYERNAME-style regex stripping/rejecting the leading.inside Hibernia'sOfflinePlayerResolver) is not in this repo — it lives inhibernia-framework(a submodule) and is tracked under PAR-109. If a Bedrock name still fails after this ships, it's that framework path, not the gov-pay command.