From 8fb561338a9a49d62e1902bc73e8562667046971 Mon Sep 17 00:00:00 2001 From: Emi Matchu Date: Fri, 9 Feb 2024 08:16:00 -0800 Subject: [PATCH] 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! --- src/server/types/PetAppearance.js | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/server/types/PetAppearance.js b/src/server/types/PetAppearance.js index 47336e5..2036036 100644 --- a/src/server/types/PetAppearance.js +++ b/src/server/types/PetAppearance.js @@ -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);