When adding new entities into a query's cache using updateQueryData, "api.provided" isn't updated (UPDATED)

[dutziworks]

When calling updateQueryData, is there a way to update the provided tags of the query whose cache was updated?

Our optimistic update needs to opt. CREATE an entity (that didn’t exist before) and add it into a query’s cache.

That new entity is now inside the cache, but not listed inside api.provided, since it didn’t go through the “regular” flow (fetched through a list/get endpoint).

Is there a way to also update that list/get endpoint’s provided tags?

[dutziworks]

Looking at the source it seems like there isn't a way to update the provided slice (or "invalidation slice").

So to achieve our goal, we'll probably have to maintain an "extendedProvided" slice, shape it as RTKQ's provided slice and update that one instead, which will work, but feels a bit weird...

The reason we need to update the provided tags of a (list) query is that we later use that data to "know" which queries to optimistically update later on, when mutations occur. And, though I am biased, it makes sense to me that the provided tags should be in-sync with the queries’ cache.

Our app is built in a way where all the data is fetched once, and from that point on, no invalidations ever occur. Everything is optimistically/pessimistically updated. We also set up DB subscriptions for all "active" queries (all mounted useList/Get...Query() hooks) so that if other users make changes to the DB everyone gets synced.

Will it be accepted if I make a PR that adds 2 (exported) case-reducers into invalidationSlice: providedTagAdded and providedTagRemoved, which accept somethings like { tagType: TagTypes, id: EntityId, cacheKey: QueryCacheKey }, and adds/remove those entities from the provided slice for that tagType/cacheKey?

[phryneas]

You are perfectly right, that should never have been missing.

Unfortunately, I just don't have the capacity to see this through myself right now fully - but I would be very open to a PR to add provided calculation to updateQueryData.
I have taken a short stab at this, and it seems plausible - so you would not start from zero, this is an outline on how such a fix would look like: 3c34511

Of course, this doesn't come without it's own problems: This would call providedBy with a different meta than usually, so it has to be toggleable if providedBy should be called in an updateQueryData case.
Maybe you could just follow this a little more? I think that would be more useful in general than having providedTagAdded and providedTagReduced?

[dutziworks]

Hey @phryneas, I submitted a PR (just code changes, no tests or updates to docs yet as I wasn't sure whether or not this would get approved).

I ended up adding updateProvided to both UpdateQueryDataThunk and PatchQueryDataThunk.

I exposed a new case-reducer from invalidationSlice -- updateProvidedBy, and I'm applying it from within patchQueryData, instead of "responding" to it using an extra-reducer, and that's because that extra-reducer (inside invalidationSlice) would not have access to all the data required by calculateProvidedBy.

Hope this works out!

[markerikson]

That was #3255 .