Fix PetAppearance ID when there's an Alt Style

I don't think this actually affects any clients in practice, but now
that `PetAppearance` can be influenced not just by pet state ID but
also alt style ID, it's no longer correct to just use pet state ID as
the `id` (the default cache key). This could theoretically cause an alt
style to be locally cached as the default appearance of a
species/color/pose.

Instead, we now append an extra string in the case that there's also an
alt style influencing the appearance. This is a bit of a mess, because
I know there's some tooling that's expecting this field to be strictly
the pet state ID, mainly for support/debugging purposes I think? But I
imagine that's not a big deal in practice, and this change should
narrow the scope of a bug like that to just be like, "error: pet state
123-with-alt-style-456 not found" when trying to save a change to it
or something. Good enough!
This commit is contained in:
Emi Matchu 2024-02-09 08:16:00 -08:00
parent 98eb14853c
commit 8fb561338a

View file

@ -73,7 +73,11 @@ const typeDefs = gql`
}
type PetAppearance @cacheControl(maxAge: ${oneHour}, staleWhileRevalidate: ${oneWeek}) {
"""
NOTE: In the case of an alt style, this won't match petStateId!
"""
id: ID!
species: Species!
color: Color!
pose: Pose!
@ -269,6 +273,12 @@ const resolvers = {
},
PetAppearance: {
id: ({ id, altStyleId }) => {
if (altStyleId != null) {
return `${id}-with-alt-style-${altStyleId}`;
}
return id;
},
color: async ({ id }, _, { petStateLoader, petTypeLoader }) => {
const petState = await petStateLoader.load(id);
const petType = await petTypeLoader.load(petState.petTypeId);