Mark Erikson

I believe this is handled by the upstream https://github.com/oazapfts/oazapfts library

@mattoni we can bump the version on our side, but assuming it's a minor release upstream, there's technically nothing _we_ need to do here for people to take advantage of...

@SimonEggert sorry, clarify what new version of `oazapfts` has the fix? Looking at https://github.com/oazapfts/oazapfts/releases , I do see that they're working on betas for a v6 major, but I'm not...

I've actually mostly tried to _not_ add links to the style guide, in contrast to the other docs page. Could be worth reconsidering, but for now let's hold off on...

@aymather there's no comments and no PRs, so no update :) (As usual, we're open to external PRs that might try to address this, but it's not on our priority...

That seems to be exactly the behavior you "asked for" by specifying `fixedCacheKey`. There is _one_ cache entry for that mutation, no matter what the arguments are, therefore there is...

I think this is still a "that is what _your code_ has configured it to do" thing :) Internally, RTKQ keeps data in the Redux store as lookup tables where...

Yeah. To be honest we probably _could_ (and _should_?) prefix it. Not sure why we didn't. I can't immediately think of a good reason why you would ever _want_ separate...

Yeah, tell you what, go ahead and file a PR. I expect that the actual fix is just going to be something like `endpoint.name + fixedCacheKey`, maybe in a couple...

My own take is that _I don't like that pattern_ :) My first reaction is that using a mutation to read data is a bad approach in the first place...