Issue with urql-cache when combining notifications query with newNotification subscription

[zcahsja]

I'm working on a reddit clone app and have set up a newNotification subscription which is triggered whenever a user votes on a post. I am trying to combine the accumulated results from the newNotification subscription with a (paginated) notifications query.

Initially I tried to do this the way it is recommended in the docs as below:

const [variables, setVariables] = useState({
    limit: 3,
    cursor: null as null | number,
  });
  
const [{ data: notifsQueryData, fetching: notifsQueryFetching }] = useNotificationsQuery({ variables });  

const handleSubscription = (messages: any = [], response: any) => {
      return [response?.newNotification, ...messages];
    };
  
const [{ data: subNotifsData, fetching: fetchingSubNotif, error }] =
    useNewNotificationSubscription({
      variables: { userIdOfReceiver: data?.me?.id! },
    },
    handleSubscription);
    
  const displayedNotifs = [
    ...(subNotifsData ?? []),
    ...(notifsQueryData?.notifications.notifications ?? []),
  ];
// we then use displayedNotifs for the render

The issue with the above implementation is that if I then navigate to another page and reopen my notifications, I lose the subNotifsData and since the cached notifications query wasn't updated - this results in outdated notifications (displaying only those from the original query result).

I tried to get around this by first updating the notifications query with the cache.updateQuery fn inside my urql-client cacheExchange by appending the below to the updates object, and then just using notifsQueryData as my displayedNotifs however this produces a different bug where the first time I trigger the newNotification subscription it works as expected, however after the 1st trigger I occasionally only see the most recent newNotification (as well as the initial query results before updates) displayed since the data variable in my update query function is incorrectly reading the original notifications query rather than the one which has just been updated via the previous subscriptions.

Subscription: {
        newNotification: (_result, args, cache, info) => {
          cache.updateQuery(
            {
              query: NotificationsDocument,
              variables: { limit: 3, cursor: null },
            },
            (data: NotificationsQuery | null) => {
              if (!data) return null;
              data.notifications.notifications.unshift(
                _result.newNotification as any
              );
              return data;
            }
          );
        },
      },

I've tried invalidating the cache each time the newNotification subscription is triggered however this doesn't integrate with pagination.

The ideal solution would be either ensuring that when I update the cache I am updating the most recently updated version of the cache rather than the initial cached query result. Alternatively another ideal solution would be a way to invalidate the notifications query cache when I lose access to my subscription data.

[kitten]

I wish I could tell you that live queries were already a thing — but unfortunately they're not 🥲

Anyway, can you expand on this please? It sounds like you've got a good handle of what's going wrong, but unfortunately I'm not quite sure here what the full story and issue re. this:

1st trigger I occasionally only see the most recent newNotification (as well as the initial query results before updates) displayed since the data variable in my update query function is incorrectly reading the original notifications query rather than the one which has just been updated via the previous subscriptions.

This should basically work and I'd expected it to work (with some limitations).

If you have a notifications query, and I'm assuming once the notification comes back, the API is expected to also contain that new notification if you were to query it, your update is somehow being erased? Is that right?

Basically, let's say you fetch your query data once, and then the subscription updates it,
I'd expect that an update that updates the notifications list is always “cumulative” and you can edit the list for each notification, adding to the results of the last one, unless:

• you have an ongoing optimistic update
• your query is experiencing and cache miss and must refetch

So, let's make sure that none of the above is happening first 🤔

[kitten]

I just added a new code example to demonstrate how this works.
Maybe this helps us to compare what you've got and what is expected to work ✌️
https://github.com/urql-graphql/urql/tree/main/examples/with-subscriptions-via-fetch

[zcahsja]

Thank you for the response.

To expand on this, lets say I have 3 returned notifications ['notif3', 'notif2', 'notif1'] in my initial notifications query. When I then vote on a post, this vote mutation awaits the insertion of a new entry into my notifications table and then triggers the newNotification subscription which subsequently updates the cache and my notifications query result becomes ['notif4', 'notif3', 'notif2', 'notif1'] as expected.

However when I then vote on another post, following the same logic I would expect the notifications query result to become ['notif5', notif4', ... , 'notif1'] but what is occasionally happening is that the result becomes ['notif5', 'notif3', 'notif2', 'notif1'] which to me seems like either the cache is occasionally missing the update or the cache is being updated but the stored value to be updated is that of the initial notifications query before any subscriptions were triggered. The strange thing is this bug doesn't always happen (around ~50% of the time) and I've also noticed that if I open 2 localhost tabs and do all the voting on tab 1, tab 1 experiences the occasional bug I described above however tab 2 works perfectly as expected - no missed cache updates.

I have found a hacky way to get the desired behaviour by invalidating the notifications query cache inside the vote mutation object of the cacheExchange, and changing the logic inside my Navbar component which displays the notifications to the below

const [variables, setVariables] = useState({
    limit: 3,
    cursor: null as null | number,
  });
  const [{ data: notifsData, fetching: notifsFetching }] =
    useNotificationsQuery({ variables });
  const handleSubscription = (
    messages: any = notifsData?.notifications.notifications,
    response: any
  ) => {
    return [response?.newNotification, ...messages];
  };
  const [{ data: subNotifsData, fetching: fetchingNewNotif, error }] =
    useNewNotificationSubscription(
      {
        variables: {
          userIdOfReceiver: data?.me?.id!,
        },
      },
      handleSubscription
    );
  const [{ fetching: logoutFetching }, logout] = useLogoutMutation();
  let body = null;
  const [popUp, setPopUp] = useState(false);
  const handleNotifClick = () => {
    setPopUp(!popUp);
  };

  const subAndQueryNotifs = [
    ...(subNotifsData ?? []),
    ...(notifsData?.notifications.notifications ?? []),
  ];

// We invalidate the notifications query after every vote
// This results in subAndQueryNotifs array storing some duplicate notifications which are handled below

  const uniqueNotifs = [];
  const idSet = new Set();

  for (const notif of subAndQueryNotifs) {
    if (!idSet.has(notif.id)) {
      idSet.add(notif.id);
      uniqueNotifs.push(notif);
    }
  }
  
  // We then use uniqueNotifs inside our component render

This results in both tab 1 & tab 2 displaying the expected data, and I also don't encounter the bug from navigating to another page since losing my subNotifsData doesn't matter as the notifications query will have been invalidated and therefore display up to date data on the new page.

Having said that, this hack doesn't feel right and I am wondering if I am missing something simple or if the bugs I have described above are actual issues?