PlayerProfile#complete does not fill the profile name when given a UUID

[EvertBt]

Expected behavior

When calling PlayerProfile#complete, it should fill both name and textures is supplied with a uuid.

Observed/Actual behavior

the textures will be filled after complete is called. the profile name will be null, you need to call update to make a second api call to fill the name, even though when printing the textures, it shows the name.

Steps/models to reproduce

PlayerProfile profile = Bukkit.createProfile(UUID.fromString("b03e2273-140b-4990-bc94-fd9350414d71"));
profile.complete();

System.out.println("name: " + profile.getName()); // null, even though the name is given in the textures
System.out.println("id: " + profile.getId()); // b03e2273-140b-4990-bc94-fd9350414d71
System.out.println("textures: " + profile.getTextures()); // will return textures

profile.update().thenAccept(updated -> { //Makes a SECOND api call to get the name
    System.out.println("name after update: " + updated .getName()); // Kalcite
});

Plugin and Datapack List

none

Paper version

git-Paper-431 (MC: 1.19.3) (Implementing API version 1.19.3-R0.1-SNAPSHOT) (Git: e574412)

Other

No response

[EvertBt]

im not sure what i did earlier but for whatever reason now the name doesn't even fill after update, i apologize for the mistake

[emilyy-dev]

The profile properties are copied but the name isn't, even though the HTTP call does return the name as well, I wonder if this is intentional https://github.com/PaperMC/Paper/blob/e57441254dc93fa70782c10f9a22c87dc98ca0b6/patches/server/0143-Basic-PlayerProfile-API.patch#L248-L279

This has the added bonus of complete and isComplete() always returning false if the profile was created only by UUID!

[electronicboy]

it's a mutability issue, best we could do is add methods that return the new profile, or store the resolved profile in a seperate field so that the methods themselves can redirect over

[lynxplay]

I mean, preferably we can use update() ? It already returns a fresh copy/clone of the previous profile and would hence avoid mutating the existing instance.

[electronicboy]

Not sure what you mean;

The issue here is the hashcode, if you change the uuid/name on a profile, it would cause the hashcode to change of the wrapper object we have

[lynxplay]

Spigot added their own PlayerProfile stuff not so long ago which included

CompletableFuture<? extends PlayerProfile> update();

The method is implemented by our CraftPlayerProfile and returns a fresh clone of the profile it was called on.

@Override
public @NotNull CompletableFuture<PlayerProfile> update() {
    return CompletableFuture.supplyAsync(() -> {
        final CraftPlayerProfile clone = clone();
        clone.complete(true);
        return clone;
    }, Util.PROFILE_EXECUTOR);
}

Here we could provide the properly updated profile with filled in username without messing with the hash.

[electronicboy]

Well, yea, but that doesn't fix the expected behavior of the current class/methods? I'm honestly confused on what you're getting at here

[lynxplay]

Yea, it leaves the complete method broken, but Idk if it is worth the ABI break ? I was suggesting to pretty much just leave them "broken" or well, specify that they only complete the properties and make update the method that fully fills profiles.

[electronicboy]

Well, it was an "or" situation;

We could avoid the ABI break and just store the "completed" profile in a separate field, and then the get style methods will defer to the completed object when its completed; otherwise, pretty much all of our methods on that class need to be deprecated