Avoid stale organization data when calling UpdatePartner

Author: CarsonF

src/scenes/Partners/Detail/PartnerDetail.graphql

@@ -6,14 +6,20 @@ query Partner($input: ID!) {
 
 fragment partnerDetails on Partner {
   ...Id
-  createdAt
+  ...partnerOwnDetails
   organization {
     canRead
     canEdit
     value {
       ...organizationDetails
     }
   }
+}
+
+# Seperated for UpdatePartner mutation
+fragment partnerOwnDetails on Partner {
+  ...Id
+  createdAt
   pointOfContact {
     canRead
     canEdit

src/scenes/Partners/Edit/UpdatePartner.graphql

@@ -4,7 +4,20 @@ mutation UpdatePartner(
 ) {
   updatePartner(input: { partner: $partner }) {
     partner {
-      ...partnerDetails
+      # Organization data cannot be fetched here as it will be stale.
+      #
+      # The API executes these two mutations in parallel, independently.
+      # `Partner.organization` doesn't know it there's another organization update going on,
+      # and will return the stale data.
+      # Apollo Client would then receive two sets of org data:
+      # - `updateOrganization.organization` result
+      # - `updatePartner.partner.organization` result
+      # They will be conflict, with the former fresh, and the latter stale.
+      # We can avoid this race / nondeterministic behavior by only returning one org data set.
+      #
+      # Also, Apollo Client still has the normalized organization for the partner record,
+      # so it knows how to connect it together when requested for the detail page.
+      ...partnerOwnDetails
     }
   }
   updateOrganization(input: { organization: $organization }) {