Does not clear cache when a relation has been updated

[willryanuk]

One of my Collection Types (Broadcast) has a "relation" to a Host... However, when i update the Host (e.g. change their name), the Broadcasts endpoint does not update the relation to reflect the new name.

[mvaisberg]

hey @willryanuk did you find a way to clean the cache of the relations?

[willryanuk]

@mvaisberg i think I either pressed "Purge REST Cache" on the parent collection, or perhaps just saved it, and that then regenerated the entry, and the cache was cleared.

[de-shine]

Can this case be automated to clear the cache for all the contents that have relation to that updated relation entry?

[Boegie19]

@de-shine if the strategy.clearRelatedCache = true than this should already happen

still since multiple people are saying someting about it there mind be a bug in tbe logic

just as a extra note: it will clear everyting from any related contentypes

[jomarmontuya]

I've also encountered the same, when content relation is updated the cache where it was use is not purge automatically

[Mirasaki]

It's almost been a year, is there any status update on this issue? :)

[Mirasaki]

I found the issue after some debugging. Super weird, but the following line doesn't seem to finish execution - or is having some other issue.

plugin-rest-cache/packages/strapi-provider-rest-cache-memory/lib/MemoryCacheProvider.js

Line 37 in 7e08dc4

return this.cache.del(key);

If you use the following, the (stale) cache invalidation issue goes away:

    const response = await this.cache.del(key);
    return response;

I've created a pnpm patch for my project, and we no longer receive reports of caching issues. I hope this is useful to some of you :)

I will definitely update this comment if we find anything else, or start receiving reports again (over 16 hours with no new reports, was around 25~ per day before haha)

Edit:

It's actually much weirder... The fix wasn't the above alone, my patch still included the debugging which somehow fixed the issue?

Running locally with just the "fix" above doesn't resolve the issue. Running the following does seem to resolve it:

  /**
   * @param {string|string[]} key
   */
  async del(key) {
    console.log('MemoryCacheProvider.del#key', key);
    const debug = async (fn) => {
      if (key.startsWith('api/products') || key.startsWith('local-development-01/api/products')) {
        await fn()
      }
    }
    debug(() => console.log('MemoryCacheProvider.del#key', key));
    await debug(async () => console.log('MemoryCacheProvider.del#has', await this.has(key)));
    const response = await this.cache.del(key);
    debug(() => console.log('MemoryCacheProvider.del#response', response));
    await debug(async () => console.log('MemoryCacheProvider.del#postDeleteHas', await this.has(key)));
    return response;
  }

  async has(key) {
    return (await this.keys()).includes(key);
  }

I was just doing some things to try and debug the issue, and using the above in a pnpm patch does fix the issue. I am very confused haha. My best bet is that it is something to do with the keys iterator.

The cache seems to invalidate after the first fetch after deleting the cache key, which is already better than it not invalidating at all - we will use this for now and see if we find anything else.

[Mirasaki]

I could personally not verify that the getRelatedModelsUid has an issue with missing relations.